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?

  • 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

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?

  • 3
    I disagree, this is trivial using Subversion. – Justin Shield Aug 4 '11 at 3:56
  • 3
    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
  • 1
    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
  • 3
    though git does make branching much easier it is not a magic wand that makes merge complexity disappear. It will not resolve a poor architecture resolving in a lot of coupling between features. Even with a good architecture some interdependence is to be expected. Simply pulling out a changeset may work for the trivial cases but reality is often more complex than hello world examples. – Newtopian Apr 20 '16 at 13:54
  • Config : You can disable the feature, make it unavailable or hide it from the product owner and plan in the next sprint what will effectively be done with this (fix or complete removal). This requires a bit of planning, some config and has some impact on how you code the feature. Also known as feature switch or feature toggle.

  • Code Isolation : As many have stated feature branches will help, and for this git would help but it's perfectly feasible in SVN as well. Up to you to decide how much work will switching VSC will be and the impact on your team. With feature in their own branch it might be easier to pull out unwanted code but it's no panacea. Depending on how your app is structured it can go from trivial to nearly impossible even with feature branches.

  • Architecture : If your system is build around a loosely coupled group of modules or plugins then removing a feature simply means not including a DLL or JAR (or whatever your stack has for this). With this approach features would actually be developed as their own separate projects (most likely).

Still nothing really can replace good communication with the product/owner, and even with this this situation is bound to happen at some point in some shape or form. You will have to negotiate with then to find the best compromise.


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.