I’m on a multi-year long-term project, I came on in just in the last year, and I and a colleague have done some serious improvement from what was a less-than auspicious starting point, starting (this is where my involvement came in) firstly with getting the whole mess into SVN. This has been helpful in numerous ways, some of which I really didn’t understand at the time. My initial thughts: there is no reasonable way to have multiple people working on the same codebase without some file checking mechanism of some sort. I’d used SourceSafe at a previous job, and back in school, RCS, and while file locking was problematic when someone went on vacation with things checked out, at least solved the basic problem of people stomping on each others’ work. I’d heard SVN was better because of the merging vs. exclusive locking I’d used in the past. I was admittedly, really, really skeptical about this, but decided to give it a go. I’d also been hearing rumors about Git and a few other things, but decided just picking one was a best path as any of these choices would be 1000 times better than no source control, and it sounded like migration things were in abundance anyway if we changed our minds. Besides, we wanted HTML coders to use the thing, so something that had a gui available to avoid arcane command-line stuff (Tortoise SVN in this case) seemed the best choice.
As it turns out, SVN has been beneficial in many, many more ways than the simple collision avoidance I’d wanted it for. A few are listed here…
1) Branching. We spent several months in development for a new version of our product. During that time, we had to do numerous bugfixes on the maintenance code. Having a separate branch for the current live codebase allowed us to have a clean copy of what was live, make fixes, and then merge over as need to the live branch. It really saved us work, and allowed us to deal with the live and development codebases together in a way that saved a bit of our sanity.
2) blame. A command I didn’t even discover for a while, it really allowed me to find the answer to “why is this here?” A question I’ve had many times of mystery bits of code in my career. Now, I can see who did a change, what checkin, and when. I can see notes telling me what that checkin was for, and if the person is still around, I know who to question on reasons if needed. The value of this cannot be overestimated.
3) Tracking what a particular person does. This may sounds spy-like, but if you have a particularly good developer on your team whose code you want to learn from, a person who you know is working on critical things you want to follow, or a more junior developer whose code you want to keep tabs on, it’s invaluable to be able to simply look at that person’s checkins. It’s easy to look at every single line of code that person entered.