Am 17.02.2010 um 16:46 schrieb Rob van Oostrum: > On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann > <philipp.leusm...@rwth-aachen.de> wrote: > 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? > > Regards, > Philipp > > 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. > > > > http://subversion.apache.org/docs/community-guide/releasing.html#releasing > > > > BOb > > > > > What you're proposing is perfectly valid. Of course, what's best depends on > organizational and practical factors. The advantage of your proposed solution > is that you fix problems where they occur. You deal with the immediate > concern (getting the bug fix out to the customer), and you do your > housekeeping (merging the fix so it's included in future releases as well) > after the fact. Any merge issues that occur will not delay resolution of the > immediate problem at hand. > > The potential downside is that your fix may not integrate well with a more > current revision of your codebase, which may cause disruption/delay on your > regular work stream and adversely affect downstream timelines. > > A third alternative might be to a) fix the problem where it needs fixing the > soonest (in your scenario on a branch created off the release tag), b) create > an integration branch for any of these types of fixes to be merged with > ongoing development and c) merge this work back into the main development > stream once integration issues have been resolved. This ensures that your > immediate problem gets fixed without delay, your ongoing development isn't > disrupted by these fixes being merged back, and you are dealing with the > integration issue. Of course the drawback to this is that you have to assign > resources to work on the integration issues which takes away from something > else getting done. > > R.
Rob, thanks for your answer. I think your alternative isn't going to be necessary, since releases are created quite regularly, so the codebase in the trunk does not differ from the last release-branch that much. But my main question from the original post is still unanswered: In the case of (overlapping) branches, would I merge the patch from releasebranch X.Y to trunk AND to releasebranch X.Y+1 ? And is it ok, if I later merge releasebranch X.Y+1 into trunk? That way the original patch would be "merged into trunk twice". Is this case handled by the svn:mergeinfo property? Regards, Philipp
