Implicit Branching and Merging

code 0 comments suggest edit

branches Scott Allen writes about a Branching and Merging primer (doc) written by Chris Birmele. It is a short but useful tool agnostic look at branching and merging in the abstract. This is a nice complement to my favorite tutorial on source control, Eric Sink’s Source Control HOWTO.

Another useful resource on branching strategies is Steve Harman’s guide to branching with CVS.

The primer takes a tool agnostic look at branching and points out several branching models. One thing to keep in mind is that not every model makes use of your source control tool’s branching feature. In particular, let’s take a closer look at the Branch-per-task model. This model is almost universally in use via what I call implicit branches, which are private and not shared among other team members.

Using a pessimistic locking source control system like Visual Source Safe (VSS), every time you check out a file (which grants you an exclusive lock on that file), you are implicitly making a branch as soon as you edit that file. However, this is not a branch that VSS recognizes. It is merely a branch by fact that the code on your system is not the same as the code in the repository. Also consider that other team members may be making changes to other files in the same codebase. Perhaps files that contain classes that the file you are working on are dependent. So when you check that file back in, you are performing an implicit merge.

This type of implicit branching pretty much maps to the primer’s Branch-per-Task model of branching. Optimistic locking source control systems such as CVS and Subversion make this implicit branching and merging a bit more explicit. Rather than checking out a file, you typically update your local desktop with the latest version from the repository and just start working on files. There is no need to exclusively lock files by checking them out which only gives you the illusion of safety.

When you are ready to commit your changes back into the system, you typically get latest again and merge in any changes that may have been committed by other team members into your local workspace. Finally, you commit your local changes (assuming everything builds) and resolve any automatic merge conflicts (which is may not be very likely since you just pulled all changes from the repository into your local workspace unless there is a lot of repository activity going on).

The point here is to recognize that the implicit branching model (branch-per-task) is almost certainly already in use in your day to day work. It is not necessary to employ your source control’s branching feature to employ this branching model, unless you need multiple developers working on that single task. In that case, you would create an explicit branch for that task so that it can be shared. However, keep in mind that when multiple developers work on an explicit branch, the branching and merging model for that individual branch will look like the implicit branch-per-task model as I described.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

4 responses

  1. Avatar for Adam
    Adam June 2nd, 2006

    I've worked places where they only allowed exclusive locks (VSS), so there was never any merging because they felt it was too dangerous.
    I've also worked places that allowed multiple checkouts but forced us to work on our development server files directly (this was ASP2). So if we did have two people trying to modify the same ASP page we had significant issues. Teaching the people who worked there about developer isolation was a tough battle but ultimately made the environment better (obviously).

  2. Avatar for Haacked
    Haacked June 2nd, 2006

    As I pointed out though, even with exclusive locks you are implicitly merging code when you check it in.
    For example, you check out Foo.cs which has a class Foo that relies on class Bar. Another developer checks out Bar.cs which has class bar.
    You change some code in Foo and test it and it works. Unknown to you, the other developer is changing Bar and checks it in. Now when you check in Foo, the code in the repository is broken.
    The thing is, you still need to merge changes. One way is to get latest just before you checkin you get latest again and retest your code. Even then, you could both check in at approximately the same time, in which case one or the other of you must fix the build.

  3. Avatar for Travis
    Travis June 2nd, 2006

    Continuous Integration is your friend.

  4. Avatar for Haacked
    Haacked June 2nd, 2006

    True! But continous integration just lets you know sooner that you have merge conflict issues. You still have to perform the merge.
    But Continuous Integration is important to help mitigate these type of broken build scenarios. This is why we have it set up for Subtext.
    Exactly! That's why we set it up for Subtext.
    http://haacked.com/archive/...