(This is a months old-post that has been sitting in my drafts list for a while, I don’t recall why I hadn’t posted it so here it is)
We use Microsoft’s Source Safe. I’ve read numerous nightmare descriptions from within Microsoft as to how code is organized between teams and how it migrates. As I see it, the core problem lies in the way that SourceSafe (and thus Microsoft) do their branching. They literally, physically, separate the two lines of code: if you have code at version 1.2 and decide to branch there, so that you can actively continue maintaining 1.2 while working on 1.3, SourceSafe does this by creating a complete new repository for the new branch.
This makes complete sense on an end-user machine. Having my “code” directory named for the branch it is from, e.g. code-1.2 and code-1.3, makes sense. But it doesn’t make sense in the source control system.
Source Safe allows you to apply a label to a particular point in time during the source history. Other source control systems embellish on this idea by using meaningful labels which can be branched in-line. If 1.3.x is the current head of the development tree, and we need to go back and fix a bug in 1.2.x, you simply pull the files labelled 1.2.x make your changes and when you check them back in, they go back in as 1.2.x.1
This gives you a complete source history in a single repository. It makes merging changes between versions much easier. It makes it infinitely easier to work on concurrent revisions because you can branch repeatedly.
Microsoft’s source control is out of hand – different teams have their own repositories with their own unique instance of the codebase. Double check that – I’m not talking about devs with their own copy of the code on their local machine. I’m talking about the repository that they pull from. This is branching gone not just sour but thoroughly rotten.
You’ve all seen instances where the same bug has cropped up in WWIIOL, or where a bug is listed as fixed in the readme but somehow its not changed.
Well, this is primarily because we use SourceSafe, and secondly because we’re human. When you have 2 or 3 source repositories representing different versions, sometimes files don’t get checked in to the right version.
This hindrance to healthy workflow management is the biggestflaw in the SourceSafe model. It encourages coders to check-in late, when in fact coders should be encouraged to check code into their branches early, and then merge their completed and tested work into the parent branch when they are done.
Doing this establishes a workflow trend, of branch-development, merge-completion that starts with the programmers and translates up through the team. On a large project, lien managers or team leaders become responsible for up merging in changes from lower down the branch hierachy.
In a very large project, this provides you with important data on trends – it can be very useful to analyze some of the working patterns that become clear, such as regular checkins to deal with fixing common problems which might expose issues in an API design or with development tools.