9 ms·
Unfortunately, companies do occasionally change version control systems. History also tends to get lost when the codebase of one project is imported as the begi
by Poiesis 16y ago
Unfortunately, companies do occasionally change version control systems. History also tends to get lost when the codebase of one project is imported as the beginning of another.
- ondrasej 16y agoHowever, the current version control systems usually have compatibility layers and/or import tools. We have a project that started wih CVS, then moved to SVN and now runs on Hg, and we have the complete commit log (including commits from the CVS and SVN days) in the current repository.
- pvg 16y agoI don't think 'history tends to get lost'. It happens, both intentionally and unintentionally but preservation of history is a big, often deciding factor in such a switch. These types of comments are common, I think, not so much because it's so hard to migrate history but because the VCS in use doesn't have facilities for cheap local commit and there's no immediate local history. The workaround is to place important version-change information straight in the source. Which is perfectly sensible in those circumstances, I just disagree with the OP's idea that this is somehow a desirable or best practice.
- brown9-2 16y agoIf you treat the source code history as an essential artifact of the development process, and a piece of the product's history (which it is), then it is complete foolishness to switch systems without bringing the history over.