897
Here's what I do... it's simple and has worked for years. Should be applicable to software development or any kind of document management.
Caveat: I am an army of one; this won't work for team development.
KEEP A WORK LOG. Start a Word document (or .txt or anything you want) and annotate the thing whenever you make a change. Include the date and any information a future version of yourself will thank you for now. My work log consists of a huge-ass Word table, one row per change. Every year I start a new one.
It requires some discipline, but should not be an onerous task. A simple note of what you did ("changed fonts on buttons of form x") will suffice most times; when you make major changes perhaps a bit more. I suggest this instead of renaming the actual project files, since that can get crazy complicated down the road. And no, I do not spend half my day typing comments into the log; it's the work of a few minutes, usually just prior to an archive function.
The payoff is this: Anytime in the future you'll be able to search for the date, perhaps a build number, and keywords to find when a particular bug/feature crept into the code. Using the build number, you can then track down the exact archive containing the source for that build. (Or the revision of the map file, or the latest tweak to Aunt Erma's cookie recipe.)
Archive? Yes. See below...
1. My work consists of a massive VB project, many files of varying types, any one of which might change during an edit session. The work log .doc is included within the archive.
2. When I feel the need for a backup -- prior to compiling, prior to release, or just because I'm nervous about some crazy stunt I'm about to pull -- I run a batch file that refreshes a .ZIP archive with all the files in my project.
3. When the batch completes, I rename the file with today's date, the current build I'm working on (#.#.#) and a letter A-Z denoting which build-of-the-day is in the archive. Sometimes I'll also add a comment in the filename, for example:
Backup 2007-10-02 v2.0.53a - Replaced all occurrences of True with False.zip
(Usually the renaming consists of overtyping the date and build ID; the work of a few keystrokes.)
4. Finally, the archive is copied to a 500GB backup drive on my network set aside for the purpose. I have archive files going back to 2002, including all the worklogs. The backup drive is in turn backed up multiple times to various places and media, including a PaperBack printout which consumes the warehouse next to my home. :-)
So how do I use this?
A typical scenario is that a customer calls and complains that feature x stopped working with the last update. They can tell me the current (non-working) build but that's about all. I whip out my work log and search for that build number. Then I dig out the source archive for the build PRIOR to that, and isolate the form/module/class that implements the diseased feature x. I can then use UltraCompare (or Eyeball Mk I) to compare the old source with the new, and hopefully spot the change(s) responsible.
If I'm lucky there might be a work log comment from past-me identifying the exact change causing the problem. Usually these things are resolved quickly once the section of changes is ID'd.
It's not perfect, but it works for me. It's simple, non-obtrusive, as comprehensive as I want to make it, and (best of all) uses off-the-shelf technology that does not require anything more than WinZip and Notepad to get at my old code. I used to use VSS but rapidly became disgusted when it "ate" my projects occasionally, got hung up on a checked-out module, or simply self destructed. This is soooo much better (for me).
I recognize this is not geared directly to revisions of graphic files or geodata, but it could be adapted easily.
HTH,
Ralf
Recent Posts