Use Source Control

I am a big fan of Perforce. While there are other products that do a good job of source file management, I am most familiar with Perforce.

It's a beautiful little tool with very simple licensing. What's nice is that for minimal installations, they let you use it for free. Yes, you can just download Perforce and run it with no more than two clients and two users for free. You pay license fees to go beyond the free limits. But hey, if its just you and your maps, go for it.

What a beautiful tool. Any time you want to make a change to a map, you simply check it out, make your changes, document your changes, test your changes, and check it back in. Perforce maintains a complete history of your changes so you can always go back to an earlier version, or find out just when a particular change was made.

Now the map source file is traditionally a proprietary binary file with a .map extension. Newer versions can save the map in xml format. In this article, I shall discuss the binary .map form.

Source code is traditionally in a text form, like .cpp or .java, etc. Perforce is just as happy to check in binary files. You can check in anything: pdf files, zip files, whatever. One thing it does very nicely on text files is to do a nice text comparison, thus highlighting the actual changes. And if changes are made by more than one person, it lets you merge the changes. You cannot do this with a binary file, and even if you could, it would likely make the map unstable.

Still, it is nice to be able to compare the changes to know what was changed.

What I always do is to use the File->Print to File option and then save the generated .txt file alongside the map. I usually use the same file name as the map source, but with a .txt extension. You must be careful here in that the Print to File option does not warn of overwrite. After I expert this file, I always Save the map file again, just to be sure.

Now I can always check-in / check-out the map and text mapping report in tandem. If I need to trace down a change, I can simply compare different versions of the mapping report.

One catch here is that constants and codelists do not always write to this file in the same sequence, and therefore often falsely report changes in that section. Still, for what you need to do, this method works very well.

For implementation on a Gentran for Windows system, I typically make the test server one client and my workstation another client. I discourage map source on the production server. The back end file server for Perforce should be a file server that is routinely backed up.