My best experience with source control trees have been in shops that didn’t have them to start with. At that point you have a blank slate and you can do a reasonable job of organization. The ones where they used to have VSS and migrated into CVS and then Clearcase are generally just a mess. You have a lot of historical junk that’s poorly organized.
My current situation is messy:
- The first source control system was VSS. Unfortunately a few projects are still stored there as there was not a wholesale migration.
- Perforce was brought in next, but largely the organization was organic instead of organized. Despite being a commercial solution I’ve actually found Perforce to be a reasonable source control system.
- Despite being deployed on a UNIX box many of the directories including top level directories include spaces. This causes a nasty issue with the Perforce plugin for Hudson where you can’t use the plugin because it refuses to escape a directory with spaces correctly.
Our eventual solution is to migrate to subversion or maybe even git. Unfortunately we have to live with the current pain for now.
When I was at company which has a long history of different source control tools implemented there (VSS, then CVS, then another version of VSS) we’ve chosen a pretty reasonable approach: play as you’d be setting up source control from a scratch.
We’ve change a tool to Subversion, but added there only code of active projects. Whenever someone needed to change in sources for the first time since ‘migration’ they had to check it out form the previous tool and add a project in Subversion.
This way we build quite clean source control tree since we were migrating only versions which were still active. If past versions were needed for any reason they could be extracted from the old VSS base, but as far as it was only for analysis and they were not going to any production environment we didn’t move them to the new base.