merging strategy

[Philipp Leusmann <ph...@rwth-aachen.de>]

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

Re: merging strategy

[Rob van Oostrum <rv...@gmail.com>]

On Wed, Feb 17, 2010 at 11:18 AM, Philipp Leusmann <
philipp.leusmann@rwth-aachen.de> wrote:

>
> Am 17.02.2010 um 16:46 schrieb Rob van Oostrum:
>
> On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann <
> philipp.leusmann@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
>
>
>
I'd probably merge everything back to trunk and merge from there to your
release branches from there as part of anything else being merged from trunk
to release branch. The merge back to trunk is pretty straight-forward in
terms of avoiding collisions caused by going back and forth. Specify
--reintegrate on the merge command going back to trunk to tell the client to
skip merge revisions from trunk.

R.

Re: merging strategy

[Philipp Leusmann <ph...@rwth-aachen.de>]

Am 17.02.2010 um 16:46 schrieb Rob van Oostrum:

> On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann <ph...@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

Re: merging strategy

[Rob van Oostrum <rv...@gmail.com>]

On Wed, Feb 17, 2010 at 9:09 AM, Philipp Leusmann <
philipp.leusmann@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.

Re: merging strategy

[Philipp Leusmann <ph...@rwth-aachen.de>]

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
> 

RE: merging strategy

[Bob Archer <Bo...@amsi.com>]

> 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

RE: merging strategy

["Srilakshmanan, Lakshman" <la...@police.vic.gov.au>]

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@rwth-aachen.de] 
Sent: Tuesday, 16 February 2010 6:51 AM
To: users@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