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 <stsp_at_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
>
Received on 2012-03-21 14:33:56 CET