Putting a versioned-but-not-via-source control project in source control

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.

Answer 2

Is there value in the changes made to previous versions?

If this is more or less ironed out code and it's not part of a release history of products that are in maintenance, there might be little value in maintaining the history. Zip up the directories somewhere (just in case) and place the most recent version in source control. There may be no real need to do a bunch of work to create a history that has little or no value.

As an example, when moving to a new revision control system many organizations might just start the new system with the head of the existing system (or maybe a set of branches) and have to go back to the legacy system for any history beyond the switchover date.