Motley says: “Branches are for trees, not source code”

Click & Solve » Motley says: ???Branches are for trees, not source code???

Tue, 03 Mar 2009 19:26:44 GMT

PingBack from http://www.clickandsolve.com/?p=17185

re: Motley says: “Branches are for trees, not source code”

Lior — Tue, 03 Mar 2009 23:43:39 GMT

I must disagree with you (first time for me). For me branches represent pure waste. I try to avoid them as much as I can. I think that raising up standards is a better strategy to avoid main line build issue. (every check in must pass the "quality gate")

I've posted about this some time ago (http://imistaken.blogspot.com/2008/10/source-branches.html)

re: Motley says: “Branches are for trees, not source code”

James Waletzky — Wed, 04 Mar 2009 04:35:23 GMT

Actually, Lior, I don't think we entirely disagree with each other. Branches are a great solution when used pragmatically. For a small team with a good quality gate definition, I likely wouldn't branch at all. However, for large team development, they can be a good solution.

I work in an organization that delivers software using the waterfall model (whether I like it or not and whether they admit it or not). Our team, however, follows the agile model and has to fit within the waterfall milestones. To isolate ourselves from the really hefty requirements of checking into mainline, we branch and abide by our own (sometimes stricter) check-in requirements.

Our requirements may be stricter but not as heavy. Let me explain. The overall organization leverages a continuous integration tool that could add hours of transportation time to get into mainline. We isolate ourselves from this overhead and only do it once when we reverse integrate.

Additionally, I want management to hold us accountable for results as opposed to process. Branching allows us to put our own processes in place and abide by their process only periodically at RI time. Every team is different, so I can see why they put these hard mainline check-in requirements in place.

For individual feature work, we want to maintain quality but not necessarily do fully automated test passes. The test team modifies their test suite during feature development, and the branch allows them to isolate their changes from the rest of the team until ready.

I agree with you that branches CAN represent waste (in terms of effort) when used incorrectly. If you have good reasons to branch, it is a useful tool. However, don't apply this hammer generically to solve all your problems.

Thanks for commenting, and for a thought-provoking blog posting!

re: Motley says: “Branches are for trees, not source code”

Mark — Wed, 04 Mar 2009 19:45:45 GMT

Hi James,

Interesting post. It reminds me of a post I read at Agile Development Thoughts that takes this to the next level.

http://damonpoole.blogspot.com/2008/01/advanced-multi-stage-continous.html

I have linked to the vendor's web site above. Some very interestint concepts to consider when doing continuous integration or frequent builds.

Mark

re: Motley says: “Branches are for trees, not source code”

Starvin Marvin — Wed, 04 Mar 2009 23:39:00 GMT

The key is the tools that are being used for branching. The better the tool the less resistance it is to branch and integrate. If a team uses a source control system that uses a poor merge tool and can't be configured to use Araxis or BeyondCompare then branching isn't going to be embraced by developers and testers. A better use of time is to find a better source control system.

re: Motley says: “Branches are for trees, not source code”

Starvin Marvin — Wed, 04 Mar 2009 23:39:24 GMT

The key is the tools that are being used for merging the branches. The better the tool the less resistance it is to branch and integrate. If a team uses a source control system that uses a poor merge tool and can't be configured to use Araxis or BeyondCompare then branching isn't going to be embraced by developers and testers. A better use of time is to find a better source control system.

re: Motley says: “Branches are for trees, not source code”

James Waletzky — Fri, 06 Mar 2009 19:19:39 GMT

Hey Marvin,

Agree! A good merge tool makes a lot of difference. I use Beyond Compare myself because we have a license, but have used Araxis Merge in the past and it's great as well.

Ideally you set up an automated tool that can do most of the automated resolve for you on a daily (or whatever) basis. Then a dev has to step in only to resolve conflicting changes.

As other posters pointed out (including Mark), continuous integration is a key practice for branching (or otherwise). If you have a good CI system and a small team, branches may not even be necessary. In the event they are used, minimize the levels. One of the article links above went overboard in depth IMHO.

re: Motley says: “Branches are for trees, not source code”

Kevin Dietz — Thu, 02 Apr 2009 18:15:40 GMT

MergeMagician is focused on automated merging.

http://www.mergemagician.com

<a href="http://www.mergemagician.com">MergeMagician</a>

re: Motley says: “Branches are for trees, not source code”

James Waletzky — Thu, 02 Apr 2009 19:44:06 GMT

Looks like an interesting tool, Kevin! Thanks for the reference. I'll have to thank them for the blog link too!

Any idea what source control systems it supports? It wasn't obvious on my quick look at the page and I only say "existing SCM systems".

re: Motley says: “Branches are for trees, not source code”

Kevin Dietz — Mon, 06 Apr 2009 08:59:08 GMT

The first version will support Subversion and Team Foundation Server. The next ones after that will probably be Perforce and ClearCase. There is a plug-in architecture planned so that any SCM tool will be able to be supported.