You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Browne <jk...@gmail.com> on 2005/06/22 04:58:45 UTC
2-way merging - bad?
Are there any "gotchas" with merging changes back and forth (2-way
merging) between the trunk and a branch? The subversion book seems to
imply that it's not a problem, but other things I've read say 2-way
merging is bad.. Seems like if the developers are using "clean"
working copies with no local mods when the merge occurs it should work
fine.
Any thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 23, 2005, at 4:52 PM, John Browne wrote:
> Understood. So, in your scenario you are using feature branches.
> This makes sense to me. You want to keep your feature branch up to
> date with what's going on from the trunk. But, how would release
> branches come into the picture? And, if there is a critical bugfix
> for a particular release, to what branch would you apply the bugfix
> (trunk or release) and which direction would you port it back?
>
Release branches are easy: the merging only goes in one direction.
Once a release branch is created, it *only* ever receives bugfixes
from trunk. In other words, all new bugs/features are committed to /
trunk, then selected things are merged to the release branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by John Browne <jk...@gmail.com>.
Understood. So, in your scenario you are using feature branches.
This makes sense to me. You want to keep your feature branch up to
date with what's going on from the trunk. But, how would release
branches come into the picture? And, if there is a critical bugfix
for a particular release, to what branch would you apply the bugfix
(trunk or release) and which direction would you port it back?
On 6/22/05, Ben Collins-Sussman <su...@collab.net> wrote:
>
> On Jun 22, 2005, at 1:41 PM, John Browne wrote:
> >
> > However, others say it is best to only do 1-way merges. I'm trying to
> > understand any limitations that exist with this....for a future
> > project we will be doing using subversion.
>
> There's no right or wrong answer. It's generally safest to merge all
> in one direction, then all in the other direction. If you start
> merging selected bits in both directions somewhat randomly, it's more
> likely to produce conflicts from repeated-merges.
>
> As someone already said, distributed systems like arch or svk are
> designed to track patches (and merges) from the beginning, so they're
> much better at this sort of "cherry-picking" back and forth.
> Subversion will get there too, someday.
>
> In my experience, I find that the best pattern for a long-lived
> feature branch is to merge *all* of trunk to the branch every week.
> I make sure to merge contiguous ranges of trunk, always picking up
> from the last merge-point. Then, when the branch is finished, I
> merge the whole branch back to trunk by directly comparing trunk and
> branch.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 22, 2005, at 1:41 PM, John Browne wrote:
>
> However, others say it is best to only do 1-way merges. I'm trying to
> understand any limitations that exist with this....for a future
> project we will be doing using subversion.
There's no right or wrong answer. It's generally safest to merge all
in one direction, then all in the other direction. If you start
merging selected bits in both directions somewhat randomly, it's more
likely to produce conflicts from repeated-merges.
As someone already said, distributed systems like arch or svk are
designed to track patches (and merges) from the beginning, so they're
much better at this sort of "cherry-picking" back and forth.
Subversion will get there too, someday.
In my experience, I find that the best pattern for a long-lived
feature branch is to merge *all* of trunk to the branch every week.
I make sure to merge contiguous ranges of trunk, always picking up
from the last merge-point. Then, when the branch is finished, I
merge the whole branch back to trunk by directly comparing trunk and
branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by John Browne <jk...@gmail.com>.
Ok, I have gone back and re-read the Branching and Merging section of
the Subversion book...again. ;-) In this section, the
"my-calc-branch" example demonstrates how Sally's spelling error can
be ported from the trunk back into your own branch. Then, later, all
of the development in the branch is merged back into the trunk,
including the fixes for the spelling error. This is mainly what I am
confused about. The subversion book seems to says this is ok:
-- begin svn book quote --
Instead, you and Sally might continue to share changes as you work.
It's up to you to decide which changes are worth sharing; Subversion
gives you the ability to selectively "copy" changes between branches.
And when you're completely finished with your branch, your entire set
of branch changes can be copied back into the trunk.
-- end svn book quote --
However, others say it is best to only do 1-way merges. I'm trying to
understand any limitations that exist with this....for a future
project we will be doing using subversion.
On 6/22/05, Russ Brown <pi...@gmail.com> wrote:
> Joshua Varner wrote:
> > On 6/22/05, Tim Blackman <Ti...@sun.com> wrote:
> >
> >>On Jun 22, 2005, at 12:58 AM, John Browne wrote:
> >>
> >>
> >>>Are there any "gotchas" with merging changes back and forth (2-way
> >>>merging) between the trunk and a branch? The subversion book seems to
> >>>imply that it's not a problem, but other things I've read say 2-way
> >>>merging is bad.. Seems like if the developers are using "clean"
> >>>working copies with no local mods when the merge occurs it should work
> >>>fine.
> >>>
> >>>Any thoughts?
> >>
> >>Merges don't always take into account files that have been moved in the
> >>branch or the trunk.
> >>
> >>- Tim
> >>
> >
> >
> > Here are some recent e-mails about it. I think the general consensus
> > is that merging should occur in only one direction at a time, unless
> > you want to spend the extra time to coordinate the changes b/w the
> > developers.
> >
> > http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33634
> > http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33078
> > http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=31725
> >
> > svk and arch handle this a little better since it is more fundamental
> > to the distributed VC systems, so if it is necessary for you, you
> > might take a look at those.
> >
>
> I'm currently evaluating svk for this very purpose. I've been working on
> a local branch and smerging changes from the trunk to it on a regular
> basis (and I've not had to specify any to:from revisions when doing this
> either, which is nice). The acid test will be when I come to merge the
> branch onto the trunk. Should be interesting...
>
> Just had and idea, and tried that merge-back as a dry-run equivalent
> (smerge -C). It correctly showed that it would have merged the stuff
> I've been working on and ignored what had been merged in the other
> direction.
>
> So far so good!
>
> > Josh
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by Russ Brown <pi...@gmail.com>.
Joshua Varner wrote:
> On 6/22/05, Tim Blackman <Ti...@sun.com> wrote:
>
>>On Jun 22, 2005, at 12:58 AM, John Browne wrote:
>>
>>
>>>Are there any "gotchas" with merging changes back and forth (2-way
>>>merging) between the trunk and a branch? The subversion book seems to
>>>imply that it's not a problem, but other things I've read say 2-way
>>>merging is bad.. Seems like if the developers are using "clean"
>>>working copies with no local mods when the merge occurs it should work
>>>fine.
>>>
>>>Any thoughts?
>>
>>Merges don't always take into account files that have been moved in the
>>branch or the trunk.
>>
>>- Tim
>>
>
>
> Here are some recent e-mails about it. I think the general consensus
> is that merging should occur in only one direction at a time, unless
> you want to spend the extra time to coordinate the changes b/w the
> developers.
>
> http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33634
> http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33078
> http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=31725
>
> svk and arch handle this a little better since it is more fundamental
> to the distributed VC systems, so if it is necessary for you, you
> might take a look at those.
>
I'm currently evaluating svk for this very purpose. I've been working on
a local branch and smerging changes from the trunk to it on a regular
basis (and I've not had to specify any to:from revisions when doing this
either, which is nice). The acid test will be when I come to merge the
branch onto the trunk. Should be interesting...
Just had and idea, and tried that merge-back as a dry-run equivalent
(smerge -C). It correctly showed that it would have merged the stuff
I've been working on and ignored what had been merged in the other
direction.
So far so good!
> Josh
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by John Browne <jk...@gmail.com>.
Thanks for the information. The thread in the third link above brings
me to another question. It mentions that the trunk is typically used
for enhancements and bugfixes, then changes ported to a specific
branch for releases. I always thought it was the other way
around.....maybe a branch such as "/branches/development" that was
ported back into the trunk, then the trunk is tagged and releases are
created from the trunk.
Or do I have it backwards? :)
On 6/22/05, Joshua Varner <jl...@gmail.com> wrote:
> On 6/22/05, Tim Blackman <Ti...@sun.com> wrote:
> > On Jun 22, 2005, at 12:58 AM, John Browne wrote:
> >
> > > Are there any "gotchas" with merging changes back and forth (2-way
> > > merging) between the trunk and a branch? The subversion book seems to
> > > imply that it's not a problem, but other things I've read say 2-way
> > > merging is bad.. Seems like if the developers are using "clean"
> > > working copies with no local mods when the merge occurs it should work
> > > fine.
> > >
> > > Any thoughts?
> >
> > Merges don't always take into account files that have been moved in the
> > branch or the trunk.
> >
> > - Tim
> >
>
> Here are some recent e-mails about it. I think the general consensus
> is that merging should occur in only one direction at a time, unless
> you want to spend the extra time to coordinate the changes b/w the
> developers.
>
> http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33634
> http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33078
> http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=31725
>
> svk and arch handle this a little better since it is more fundamental
> to the distributed VC systems, so if it is necessary for you, you
> might take a look at those.
>
> Josh
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by Joshua Varner <jl...@gmail.com>.
On 6/22/05, Tim Blackman <Ti...@sun.com> wrote:
> On Jun 22, 2005, at 12:58 AM, John Browne wrote:
>
> > Are there any "gotchas" with merging changes back and forth (2-way
> > merging) between the trunk and a branch? The subversion book seems to
> > imply that it's not a problem, but other things I've read say 2-way
> > merging is bad.. Seems like if the developers are using "clean"
> > working copies with no local mods when the merge occurs it should work
> > fine.
> >
> > Any thoughts?
>
> Merges don't always take into account files that have been moved in the
> branch or the trunk.
>
> - Tim
>
Here are some recent e-mails about it. I think the general consensus
is that merging should occur in only one direction at a time, unless
you want to spend the extra time to coordinate the changes b/w the
developers.
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33634
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=33078
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=31725
svk and arch handle this a little better since it is more fundamental
to the distributed VC systems, so if it is necessary for you, you
might take a look at those.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: 2-way merging - bad?
Posted by Tim Blackman <Ti...@sun.com>.
On Jun 22, 2005, at 12:58 AM, John Browne wrote:
> Are there any "gotchas" with merging changes back and forth (2-way
> merging) between the trunk and a branch? The subversion book seems to
> imply that it's not a problem, but other things I've read say 2-way
> merging is bad.. Seems like if the developers are using "clean"
> working copies with no local mods when the merge occurs it should work
> fine.
>
> Any thoughts?
Merges don't always take into account files that have been moved in the
branch or the trunk.
- Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org