subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philipp Leusmann <>
Subject Re: merging strategy
Date Wed, 17 Feb 2010 14:09:16 GMT
Thank for you hint, Bob, but I have doubts this way a merging works out for us, since we are
working in a small team without "voting" each task. So, I have the fear, that changesets committed
to trunk contain unrelated changes, which by accident make it into the branch.

So, it would be nice to get some more comments on my proposal. How would it work out best?


Am 15.02.2010 um 22:14 schrieb Bob Archer:

>> Hi all,
>> we are currently rethinking our svn branching strategy and one question
>> came up.
>> To explain what we are planning to do:
>> We are going to use a release-branching, with adding new features to
>> /trunk .
>> At some point in time, we will create a ReleaseCandidate-branch from the
>> trunk to /branches/Ver_X.Y , which from that point of time will only
>> receive bug-fixes, which will also be merged into /trunk.
>> At some point, we will consider it stable and tag it as Ver_X.Y .
>> Daily new work still goes to trunk and on some point we will create the
>> next RC-branch (/branches/Ver_X.Y+1)
>> Now the problematic thing happens: the customer, who has Ver.X.Y, demands
>> an immediate bug-fix. Thus, the plan is to create the bugfix in
>> /branches/Ver_X_Y .
>> But what will be the best practice to merge it? the bugfix also has to go
>> to /trunk and to /branches/Ver_X_Y+1.
>> Would I merge it to both /trunk and /branches/Ver_X_Y+1 or would I only
>> merge it to /branches/Ver_X_Y+1 which then will be merged to /trunk?
>> What is the best practice or doesn't it matter at all?
>> Thanks for your help,
>> Philipp
> You may want to look at how the subversion project itself handles this. They use release
branches as you plan however they do not commit code to the branches. All changes are made
to trunk then ported to a release branch once it is fully tested and approved.
> BOb

View raw message