SVN Workflow - Chicken Before the Egg - Before merging V1 with V2, I need code from V1 to work on V2

Question

Hi,

Our distributed team (3 internal devs and 3+ external devs) use SVN to manage our codebase for a web site. We have a branch for each minor version (4.1.0, 4.1.1, 4.1.2, etc...). We have a trunk which we merge each version into when we do a release and publish to our site.

An example of the problem we are having is thus: A new feature is added, lets call it "Ability to Create A Project" to 4.1.1. Another feature which depends on the one in 4.1.1 is scheduled to go in 4.1.2, called "Ability to Add Tasks to Projects".

So, on Monday, we say 4.1.1 is 'closed' and needs to be tested. Our remote developers usually will start working on features/tickets for 4.1.2 at this point. Throughout the week we will test 4.1.1 and fix any bugs and commit them back to 4.1.1. Then, on Friday or so, we will tag 4.1.1, merge it with trunk, and finally, merge it with 4.1.2. But, for the 4-5 days we are testing, 4.1.2 doesn't have the code from 4.1.1 that some of the new features for 4.1.2 depend on.

So a dev who is adding the "Ability to Add Tasks To Projects" feature, doesn't have the "Ability to Create a Project" feature to build upon, and has to do some file copy shenanigans to be able to keep working on it.

What could/should we do to smooth out this process?

P.S. Apologies if this question has been asked before - I did search but couldn't find what I'm looking for.

Answer 1

The way we do it is that all development happens in trunk. You only even commit to trunk and then any fixes required for 4.1.1 get merged from trunk to the 4.1.1 branch. The branch for 4.1.2 is only created when testing on 4.1.2 begins - once the 4.1.2 branch is made, work continues in trunk and if any fixes are required for 4.1.2, they are made in trunk and then merged into 4.1.2.

It's very rare that we ever make a change in a branch that needs to be merged back into trunk (or anywhere else, really).

Answer 2

I would have all new commits go into the trunk unless there's a reason to put them somewhere else. By creating different branches for 4.1.1 and 4.1.2, for instance, your example is best approached by doing merges between branches, both of which might then be merged back to trunk. Yuck! That's mergeinfo hell, in my opinion.

Here's some basic advice from the Subversion book:

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

Answer 3

I guess there are several ways to do it.

But I practice that the trunk is always stable. No unfinished - unstable code should go into the trunk. If there is a new feature to be added and it takes days, maybe weeks, then I create a branch for it. When it is done, and the branch seems stable and tested, it gets merged into the trunk again, and the branch is deleted.

This way the trunk will stay stable. And experimental code is always i the branch.

If I for some reason change my mind and skip a half done project, I dont have to think about the trunk. I simply delete the branch....

Answer 4

One approach is to branch 4.1.2 from 4.1.1 instead of from trunk (and of course 4.1.1 from trunk).

You can then easily merge 4.1.1 into 4.1.2 regularly and still be able to do the trivial merge back into the trunk for each branch when it is time to release.

Answer 5

Sounds like you need a branch X based on trunk, and a branch Y based on X.

You can develop a feature in X, and start having it tested. In the meantime, you copy X to a new branch Y, and develop the second feature there.

Eventually X gets merged to trunk and released. Then when you're finished working on Y, you can merge it back into X for testing, and then into trunk for release.

You can repeat this process after both features are released. The next time you finish a feature in X, and you want to build on it, just merge it back into Y.

If you're doing this, it's important to remember:

• You do normal merges from trunk into X, and from X into Y.
• You do reintegrate merges from X back into trunk, and from Y back into X.
• After a reintegrate merge into trunk, you need to block the commit from being merged back into X.
• After a reintegrate merge into X, you need to block the commit from being merged back into Y.
• Keep detailed notes about which feature is in which branch; otherwise this can get confusing quickly.