Thoughts in the Wilderness

Many source control systems offer the feature of “atomic check-in”. That is, when the developer checks in their changes, they are grouped together in such a way that they are all successful or unsuccessful together. Everyone agrees that say this is a core requirement of a good source control system.

The primary purpose of atomic check-in is to force the developer to resolve conflicts with other code before committing their changes. From that perspective, atomic check-in works just fine.

But there is another requirement that atomic check-in is used for. That is the ability to group arbitrary sets of changes together (an atomic change-set). From this perspective, the purpose of atomic check-in is to support the ability to easily merge a change from one code-branch into another.

If you have multiple check-ins for one “real” functionality change, then atomic check-ins start losing their helpfulness. This was not that apparent when developers only checked in code once a week. But those days are gone. Today, developers doing continuous integration check-in several times every day.

And merging those changes has become hard (again).

Source control systems are missing an additional level of change management – the ability to group sets of changes together into a single meaningful change-set.

Do any source control systems do this? I think AccuRev might, although I have not used it so I don’t know for sure. Certainly Perforce, CVS and SubVersion do not. (Perforce jobs do not count).

I found myself yesterday upgrading a set of Visual Studio solutions from VS 2003 to 2005 (actually, .NET 1.1 to 2.0). Now this is a fairly simple procedure, unless you want to maintain the link between the 2 versions in Source Control. This post documents my procedure for doing that, so that others can benefit.

If you are branching, you may as well take the time to correct past “structural” mistakes. In my case, my previous structure was to have all of the solution files in a common folder, and all of the projects in subfolders. This is a very flat, simple system, but it made it hard to:

1. Discover which solution a particular project was in (100+ projects, 20+ solutions)
2. Use CruiseControl.NET to monitor for changes (have to monitor each project individually)

So, my new structure is to have the solution file in a folder all by itself (give each solution its own folder), and then have the constituent projects in sub-folders. This fixes both drawbacks of the previous structure.

My source control system at work is Perforce (P4). In P4, you can define “branchspecs”, which are descriptions of ways in which you want to branch code. They are effectively mappings between target and destination files/folders. Once you have a branchspec describing the relationship between 2 branches, then future integrations (merges) become simple. So, step 1 was to create a branchspec, which maps the old structure to the new. Once that was created, I used the branchspec to create the branch.

Step 2 was to check out the branched files. (In P4, branching does not check-out the file automatically). I do this so as to allow VS.NET full access to the files even if source-control integration is broken.

Step 3 was to open the solution in VS 2005. The wizard is fairly simple and easy to follow. Don’t bother making a backup copy, because we are already working off of a copy. If you have missing files, don’t panic! Just revert (undo checkout) the branch, fixup the branchspec, and start again.

Now depending on environment, you may have lost source control integration in VS 2005. To fix: Go to File/Source Control/Change Source control. Multi-select all projects and click “Bind”, then “Ok”. There are usually some warnings with options after that; just choose the default options.

At this point you should have a working solution. If not, the probable cause is “reference paths”. You will need to go to the references for each project, and assign a valid reference path.

Finally, use VS.NET to check-in all changes. If, after checking in, you still have some files checked out, then one of 2 things has happened:

• A programmer removed the file from a project, but did not remove it from source control
• The file may be a dependency that was never added to the project.

In most cases, you can just revert (undo checkout) the files. If you find you need them later, you can always use the branchspec to integrate them.