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 <s...@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 >
