You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Erik Andersson <ki...@gmail.com> on 2012/03/07 15:47:31 UTC
Svn merge reintegrate question
I'm a svnmerge.py user, trying to understand core svn merging.
If creating branches from trunk, you cannot have two release branches and
keeping the release branches alive with reintegrate?
When the second release branch is merged to the trunk, the first release
branch can no longer be merged to trunk with reintegrate because then the
content from the second release branch will be removed from the trunk if
you reintegrate the first branch with trunk.
I hope this script example explains it:
http://paste.pocoo.org/show/260265/
I would really appreciate any feedback on this.
Cheers / Erik
Re: Svn merge reintegrate question
Posted by Erik Andersson <ki...@gmail.com>.
Hi
Mail filters caught this so I didn't see it until now. I appreciate your
feedback and I will look at your input as soon as possible.
Thanks! / Erik
On Wed, Mar 7, 2012 at 8:24 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Mar 07, 2012 at 03:47:31PM +0100, Erik Andersson wrote:
> > I'm a svnmerge.py user, trying to understand core svn merging.
> >
> > If creating branches from trunk, you cannot have two release branches and
> > keeping the release branches alive with reintegrate?
> >
> > When the second release branch is merged to the trunk, the first release
> > branch can no longer be merged to trunk with reintegrate because then the
> > content from the second release branch will be removed from the trunk if
> > you reintegrate the first branch with trunk.
> >
> > I hope this script example explains it:
> > http://paste.pocoo.org/show/260265/
> >
> > I would really appreciate any feedback on this.
>
> If I understand your example correctly, you want to do the following:
>
> - make changes on the 1.0 release and merge these changes to 1.1 and trunk
> - make changes on the 1.1 release and merge these changes to trunk
> - eventually create a 1.2 release from trunk -- this release is a
> superset of 1.0 and 1.2.
>
> What I don't understand is why you try to reintegrate branch 1.0 into
> trunk while no real changes were made on the 1.0 branch since the
> previous merge. You do "work" on the 1.0 branch at the very start of
> your script, but no additional work is ever done again before you merge
> the 1.0 branch to trunk a second time. Is this an oversight or did you
> just intend to keep the example short?
>
> As written, the script shows the problem you are pointing out quite well,
> but it doesn't really make sense in terms of a sensible merge strategy and
> therefore I am not sure what your intentions really are.
>
> What I don't understand is if you intend to make commits that are unique
> to trunk, i.e. neither in 1.0 and 1.1. Are you syncing the 1.0 branch to
> trunk in r7 in your example because trunk might have changes that should be
> merged to 1.0, or simply because the svnbook recommends to perform a sync
> before reintegration? If you make changes to both trunk and 1.0 in parallel
> and keep syncing both branches to one another, what's the point of having
> the 1.0 branch in the first place?
>
> Maybe trunk never receives non-merge commits and you'd create a 1.2
> branch from trunk as soon as you want to make a change that isn't
> suitable for 1.0 and 1.1? In this case, you could use a stair-case
> branching model instead of forking release branches off trunk:
>
> 1.2 +---------------
> |
> 1.1 +------+---------------
> |
> 1.0 ------+----------------------
>
> So you'd have no trunk at all. To prepare a new release the previous
> release is copied to a new branch with an incremented version number.
> What you would do now is always merge changes made on a branch upwards
> to the next level, e.g. a bug fixed in 1.0 would be merged to 1.1 and
> 1.2 in two steps:
>
> cd 1.1-working-copy; svn merge ^/1.0; svn commit
> cd 1.2-working-copy; svn merge ^/1.1; svn commit
>
> You can also block revisions from being merged upwards using --record-only
> merges in this model, like you do in your example. It is also easier to
> visualise the flow of changes. However, it requires that bugs are always
> first fixed in the oldest affected and maintained release.
>
> If you'd like to keep branching releases off trunk as you do in your
> script, --reintegrate is not what you need. Instead, you can regard
> your merges from release branches to trunk as giant cherry-picking merges.
> The release branches are never reintegrated to trunk. Which means that you
> merge as you do in your example script, but remove the --reintegrate option
> from your merge commands. If I modify your script accordingly (diff below),
> the problem you see with the final reintegrate merge goes away. It's quite
> possible that this is the real equivalent of what svnmerge.py actually did.
>
> It is possible that this approach leads to unnecessary conflicts in
> practice. I'm not quite sure if that will be the case because of the
> unknown aspects of your overall merge strategy. Following the flow of
> change also is a bit harder than in the stair-case model. So I'd recommend
> to consider a switch to the stair-case model if it is applicable to your
> situation.
>
> --- 260265-orig.sh Wed Mar 7 19:57:32 2012
> +++ 260265.sh Wed Mar 7 20:02:57 2012
> @@ -59,7 +59,7 @@
>
> # Reintegrate branch1_0
> svn up $trunk
> -svn merge --reintegrate $branch1_0_url $trunk
> +svn merge $branch1_0_url $trunk
> svn ci $trunk -m "reintegrate 1.0 branch into trunk"
>
> # Keep 1.0 branch alive, we need to do more work still.
> @@ -75,7 +75,7 @@
>
> # Reintegrate 1.1 branch
> svn up $trunk
> -svn merge --reintegrate $branch1_1_url $trunk
> +svn merge $branch1_1_url $trunk
> svn ci $trunk -m "reintegrate 1.1 branch into trunk"
>
> # We don't want this changeset merged to an older release.
> @@ -96,7 +96,7 @@
>
> # Now, if I try to reintegrate branch1_0 to trunk I will get in trouble..
> svn up $trunk
> -svn merge --reintegrate $branch1_0_url $trunk
> +svn merge $branch1_0_url $trunk
> svn diff $trunk
>
> # the changes commited in 1.1 branch is reverted since it doesn't exist in
>
Re: Svn merge reintegrate question
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 07, 2012 at 03:47:31PM +0100, Erik Andersson wrote:
> I'm a svnmerge.py user, trying to understand core svn merging.
>
> If creating branches from trunk, you cannot have two release branches and
> keeping the release branches alive with reintegrate?
>
> When the second release branch is merged to the trunk, the first release
> branch can no longer be merged to trunk with reintegrate because then the
> content from the second release branch will be removed from the trunk if
> you reintegrate the first branch with trunk.
>
> I hope this script example explains it:
> http://paste.pocoo.org/show/260265/
>
> I would really appreciate any feedback on this.
If I understand your example correctly, you want to do the following:
- make changes on the 1.0 release and merge these changes to 1.1 and trunk
- make changes on the 1.1 release and merge these changes to trunk
- eventually create a 1.2 release from trunk -- this release is a
superset of 1.0 and 1.2.
What I don't understand is why you try to reintegrate branch 1.0 into
trunk while no real changes were made on the 1.0 branch since the
previous merge. You do "work" on the 1.0 branch at the very start of
your script, but no additional work is ever done again before you merge
the 1.0 branch to trunk a second time. Is this an oversight or did you
just intend to keep the example short?
As written, the script shows the problem you are pointing out quite well,
but it doesn't really make sense in terms of a sensible merge strategy and
therefore I am not sure what your intentions really are.
What I don't understand is if you intend to make commits that are unique
to trunk, i.e. neither in 1.0 and 1.1. Are you syncing the 1.0 branch to
trunk in r7 in your example because trunk might have changes that should be
merged to 1.0, or simply because the svnbook recommends to perform a sync
before reintegration? If you make changes to both trunk and 1.0 in parallel
and keep syncing both branches to one another, what's the point of having
the 1.0 branch in the first place?
Maybe trunk never receives non-merge commits and you'd create a 1.2
branch from trunk as soon as you want to make a change that isn't
suitable for 1.0 and 1.1? In this case, you could use a stair-case
branching model instead of forking release branches off trunk:
1.2 +---------------
|
1.1 +------+---------------
|
1.0 ------+----------------------
So you'd have no trunk at all. To prepare a new release the previous
release is copied to a new branch with an incremented version number.
What you would do now is always merge changes made on a branch upwards
to the next level, e.g. a bug fixed in 1.0 would be merged to 1.1 and
1.2 in two steps:
cd 1.1-working-copy; svn merge ^/1.0; svn commit
cd 1.2-working-copy; svn merge ^/1.1; svn commit
You can also block revisions from being merged upwards using --record-only
merges in this model, like you do in your example. It is also easier to
visualise the flow of changes. However, it requires that bugs are always
first fixed in the oldest affected and maintained release.
If you'd like to keep branching releases off trunk as you do in your
script, --reintegrate is not what you need. Instead, you can regard
your merges from release branches to trunk as giant cherry-picking merges.
The release branches are never reintegrated to trunk. Which means that you
merge as you do in your example script, but remove the --reintegrate option
from your merge commands. If I modify your script accordingly (diff below),
the problem you see with the final reintegrate merge goes away. It's quite
possible that this is the real equivalent of what svnmerge.py actually did.
It is possible that this approach leads to unnecessary conflicts in
practice. I'm not quite sure if that will be the case because of the
unknown aspects of your overall merge strategy. Following the flow of
change also is a bit harder than in the stair-case model. So I'd recommend
to consider a switch to the stair-case model if it is applicable to your
situation.
--- 260265-orig.sh Wed Mar 7 19:57:32 2012
+++ 260265.sh Wed Mar 7 20:02:57 2012
@@ -59,7 +59,7 @@
# Reintegrate branch1_0
svn up $trunk
-svn merge --reintegrate $branch1_0_url $trunk
+svn merge $branch1_0_url $trunk
svn ci $trunk -m "reintegrate 1.0 branch into trunk"
# Keep 1.0 branch alive, we need to do more work still.
@@ -75,7 +75,7 @@
# Reintegrate 1.1 branch
svn up $trunk
-svn merge --reintegrate $branch1_1_url $trunk
+svn merge $branch1_1_url $trunk
svn ci $trunk -m "reintegrate 1.1 branch into trunk"
# We don't want this changeset merged to an older release.
@@ -96,7 +96,7 @@
# Now, if I try to reintegrate branch1_0 to trunk I will get in trouble..
svn up $trunk
-svn merge --reintegrate $branch1_0_url $trunk
+svn merge $branch1_0_url $trunk
svn diff $trunk
# the changes commited in 1.1 branch is reverted since it doesn't exist in