Question

I have some old code (an old but still maintained VB6 application) that from a source control point of view is the ultimate example of the plumber’s plumbing (or cobbler’s shoes). It’s been version controlled by the approach of making a new directory for each version.

Are there any major downsides to taking the following approach?

1. Do the initial check-in of all files
2. Erase all files from the working directory, then copy all files from the next version to the working directory
3. Check them in
4. Goto #2 until done

Note that I have a general change log text file which I’d grab the comments from for each version I check in/commit. I don’t have (or really care about at this point) comments on a per-file- basis.

I don’t really know at this point what files have changed between versions, and being lazy I figured I could avoid doing file compares between versions to find out, so that’s why I’m taking the approach above. Not to mention that erasing all the files first allows file deletions to be detected.

I specifically haven’t mentioned which version control tool I’m using since I’m hoping (also assuming, but maybe very incorrectly) that the answer is fairly independent. When I use terms like “check-in” I use them in the general sense, not specific to a tool.

Answer 1

That’s a reasonable approach. Some source control systems (TFS, for example) will silently ignore attempts to check in a file that is unchanged. This is a good thing. If yours doesn’t have this feature, I recommend doing a diff across all files and only checking in the changed ones. Otherwise, you add a great deal of noise to the file histories.