Thanks for a great article

Thanks. I didn’t think about about tagging. We use TFS here, and this has become a much discussed topic in the past couple days. After reading this, I was on board. I hate all the merging back and forth between the trunk and dev that happens in the standard branching strategy; it’s always seemed very sloppy to me,, so I’m ready to implement this. Sadly, my seniors don’t agree 🙁

Hi Wes,

Good question. If you want to preserve the branch before the merge was done, you can do 1 of 2 things.
1. Just use the prior SVN number (assuming you are using SVN, before the merge)
2. Just tag right before the merge.

I try to keep it simple and don’t tag unless I am finding that I am historically needing to do this.

I think the example has shown that hot fixes “can” be RI’d to the trunk. So there is no more risk than what is being done in today’s traditional branches. The same could happen in a dev, main, prod branch setup where fixes in the prod branches may not RI back to main. This is something that has to be managed whether your setup is like John’s or you have a more traditional Dev –> Main –> Prod style.
Also, remember the importance of labels within branching. Most SC gatekeepers worry about losing snapshots or the ability to revert back when simplifying branching. Labels can help alleviate these concerns.

Not always do you apply a fix from a previous release to the new release. Sometimes for the new release you do a different fix, that is more appropriate. The old release fix might be a panic “have to just get this working with duct tape” type of fix that you don’t want to move forward. You want to fix it the right way for the next release.

You are right about legacy code, but shouldn’t we move in this direction? Even if we can’t get there right now. We should have our goals set on this kind of simple branching strategy and figure out how to get there.

Thanks for the comments.

First, I’m struck that in your example Release2 reintroduces the bug that Release1 HF1 was supposed to fix. There’s nothing in this process that prevents that from happening.

Second, legacy applications (which I would argue is what the majority of developers work on) rarely have a robust set of tests – or an architecture that even supports testability. So while CI and automated testing will eventually train the team to keep trunk in a ready to release state it may be a good long while before you hit the tipping point where that’s realized. In the meantime branch-by-feature seems like a reasonable middle way.

Regards,
Rob

Thanks Peter,

About #3. What I mean there is that you shouldn’t create code that is sloppy with the idea that you will go back later and fix it. I agree 100% about being a boy scout developer.

I am trying to say there that someone should not check in code that hasn’t been refactored, or hasn’t had static code analysis violations that they know about cleaned up with the thought of coming back to it later.

#2
Automated test are VERY important … you said it twice already 😉

#3 -1
>>Don’t go back and clean up code later.
>>Write it right the first time
Cant agree with that one. It is very hard to get everything right the 1st time.
Be a boy scout developer!
-Fix code when you see something not nice
-Checkin small changes

Follow the boy scout rule:
Leave the campground cleaner than you found it.

.peter.gfader.
http://blog.gfader.com/
http://twitter.com/peitor

One other thing to note with this approach is that it’s so unbelievably easy that new members to the team are brought up to speed instantly. What’s an easier branching strategy than don’t branch if you don’t need to?