RE: merging strategy

Hi Philipp,

We use trunk as a stable stream.

All work, feature or bug fix are performed on a branch.

We merge back to trunk any changes that are ready for release. We also
use trunk to propagate changes to all development teams.

If you follow the above practise, then in your case, the bug fix in
/branches/Ver_X_Y will be merged to trunk when released. This change, as
part of regular (weekly) merge activity, will be incorporated into
/branches/Ver_X_Y+1.

When /branches/Ver_X_Y+1 is ready for release, you re-integrate
/branches/Ver_X_Y+1 to trunk. This will not cause a conflict on the bug
fix.

Hope this helps.

Thanks
Lakshman
-----Original Message-----
From: Philipp Leusmann [mailto:philipp.leusmann_at_rwth-aachen.de]
Sent: Tuesday, 16 February 2010 6:51 AM
To: users_at_subversion.apache.org
Subject: merging strategy

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
Received on 2010-02-17 23:29:51 CET