Take the 2-minute tour ×

Let's say your team is working on 10 features/fixes for a sprint. At the end of the sprint, there are one or two things that the product owner does not accept. But, they would really like the other 8 or 9 to be released.

How do you handle this? Using subversion, what would be the best methodology to manage a sprint with the possibility that this could happen?

share|improve this question
You are so screwed ... hginit.com –  Job Aug 4 '11 at 4:00
not yet :) It hasn't happened yet. I'm trying to anticipate and prepare for if/when it does. –  Amy Anuszewski Aug 4 '11 at 13:24
add comment

4 Answers

up vote 3 down vote accepted

Subversion is going to be the killer for you.

I was going to say put each feature in its own branch and merge the branches to produce the release candidate. Then if the customer decides to pull one or more features you can re-merge excluding the branches of the rejected features.

This will not be a trivial exercise with Subversion however as its' branch merging isn't apparently that great. Could you switch to Mercurial? Or Git?

share|improve this answer
I disagree, this is trivial using Subversion. –  Justin Shield Aug 4 '11 at 3:56
If you want to see trivial use Mercurial. Subversion is pretty famous for ugly merging as detailed by Joel Spolsky in his introduction to Mercurial. Theoretically SVN should be able to do this but when you have 3 developers working on 6 features that happen to hit the same bit of code in subtle ways you will not be calling it trivial, trust me. I've done that sort of merge in PVCS & it wasn't a pretty sight. –  mcottle Aug 4 '11 at 8:28
I was able to convince the rest of the team that it was time to switch to git. And, I just did my first branch and merge with git. It integrated very nicely into my IDE, and was absolute cake to do.(We picked git over mercurial because the integration with our IDE was better.) Now that it's not a scary nightmare, we will willingly do one branch per fix/feature. –  Amy Anuszewski Aug 7 '11 at 0:48
+1 Git is a good choice as well –  mcottle Aug 7 '11 at 2:06
add comment

How you handle SubVersion / Repositories

Normally what I do for something like this is I actually get all developers to write features in separate branches and then I will perform a merge to trunk, but tag that as Pre-Release.

This also gives me a chance to review each feature for correctness, if a branch or feature fails my initial QA then I don't merge it. If any feature gets dropped after it goes to QA it's then trivial to revert a specific revision from trunk and then re-tag and re-test.

share|improve this answer
add comment

If you are getting surprised by this at the end of sprints, I'd say that you need to rethink how you architect applications. There are 2 philosophies that I've come across that I recommend that you look at: Feature driven development and Software Product Lines.

With FDD, you will be thinking about your application architecture as a collection of features. Each feature should be able to stand alone, or be pulled from the project if necessary.

With software product lines, the premise is you will be making a number of different products that will have some features in common, and some features that are different. This involves more upfront design to refactor the common things into separate feature-libraries.

share|improve this answer
add comment

You really have to code in anticipation, unless the features never ever touch any common code.

If you use separate branches, then if multiple branches need changes in the same code, you'll get kind of random results by dropping any particular branch.

It's much better to build something into your requirements, and into your code, that lets you disable specific features as needed. Sometimes this will require having code for both old and new behavior; other times it will just need a way to block new behavior.

share|improve this answer
add comment

Your Answer


