Using first level branches in Plastic SCM – an strategic move

Thursday, May 31, 2012 0 Comments

It’s been a long road for first level branches in Plastic SCM but they’re reaching a renaissance after the 4.0 release.

I’m going to explain how main branches are useful and how we’ve designed the Branch Explorer to take advantage of them. Let’s go.

Strategy vs tactic

There are many types of branches (I strongly recommend getting familiar with this article and the excellent book on branching patterns by Steve Berczuk and Appleton) but for the sake of simplicity I’ll divide them into two groups:
  • Strategic branches: The ones shaping your development process in the long term. Samples are the “main branch”, release branches, maintenance branches, architecture branches, subproduct branches, and so on. They are normally few, but they’re long-lived and will be around for a while.
  • Tactical branches: The ones you use for short tasks. Typically task branches, bug fix branches, and feature branches. There are hundreds of these branches and they’re short-lived (maximum 16 hours if you stick to SCRUM, too).
    But, of course, from the version control point of view “all branches are created equal” :).

    So, my recommendation is the following:
  • Use “first level branches” for strategic branches: main, fix-3.0, hospital120, and so on
  • Use child branches for the tactical ones: /main/task1230, fix-3.0/fix3410


    This is how your Branch Explorer looks with all the branches floating around (this is, in fact, a small diagram!):
    All those branches and no simple way to distinguish the “important ones” (strategic) from the everyday task branches.

    That’s why we added “level filtering” to the GUI in 4.0:
    This way, you can select which branching level you want to see… and this is how you can take advantage of the correct strategic/tactical split, rendering the whole thing correctly on the Branch Explorer. Suppose you just select “level 1”. This is what you'll see:
    Now it is very easy to focus just on the “strategic” branches when you want to, understanding the overall project without delving into the details, and zooming into the tactical view when needed.


    Before 4.0 we discouraged the use of first level branches except for hard-core hackers, but now they’re just like child branches (except for the namespace they’re on [parent/child] type of names). They can be created and used for lots of purposes, and using them for long-lived, strategic developments really is a good idea.
  • 0 comentarios: