On Sun, Dec 20, 2009 at 06:02:22PM +0000, William S Fulton wrote:
> Hi,
>
> We have been doing regular two way merges from trunk to branch and
> vice-versa using svn 1.5. In 1.6 this results in tree conflicts. Is
> there any guidance on how to deal with this scenario?
I think you should try to avoid doing this.
It's possible but it makes it very hard to know what changes really went
where and when. My favourite branching strategies only use a one-way
street between any two given branches. Such strategies tend to be simpler
to understand for both humans and for Subversion, and in my experience
it's usually possible to melt down even the most complex branching
strategy to a pattern where merges are one-way streets.
> All I can find
> is the svn book, which only talks about tree conflicts wrt to
> working copies. I have a script attached demonstrating the general
> problem. It simply adds/deletes files on trunk, merges to mybranch,
> then merges back to trunk. In my possibly naive view, there really
> isn't a tree conflict at all as there have been no changes on the
> branch (other than what was merged from trunk!!). Perhaps we are not
> merging correctly? Although using --reintegrate when merging back to
> trunk removes the tree conflict problem, this can't be right option
> as we want to keep the branch going in order to make further
> releases.
You need to use --reintegrate.
After reintegrating a branch, there are two options for keeping the
branch going. An easy one, and one that requires a bit of understanding
about how Subversion implements merge tracking.
The easy one is that you 'svn remove' the branch after re-integrating it,
and then create it again by simply copying trunk to the branch name again.
That will work fine but you'll have to use the peg revision notation
to get at the branches you deleted in the past.
The other way is to do a record-only merge.
Let's say you created your branch in revision A, and now you just
committed revision B which made the final change to your branch
before reintegration. As you do the reintegrate merge, you commit
revision X which affects trunk -- it puts all changes you made on the
branch between A and B into trunk. So we can say that, from a semantic
point of view, the changes made on the branch between A and B are the
same changes as the ones that were made on trunk in revision X.
The thing is that Subversion doesn't know this. All it knows are paths
and revisions. It does not remember that trunk:X corresponds to the
revisions branch:A-B. You need to tell Subversion about this yourself,
to avoid the next catch-up merge from trunk to the branch to merge
revision X (the branch already has all the changes made in X).
You can do this using the --record-only option.
In a working copy of the branch, do:
svn merge --record-only -cX ^/trunk
This will only affect mergeinfo. Now after committing those mergeinfo
changes, you can run
svn merge ^/trunk
in a working copy of the branch again to soak up further changes made
on trunk.
Stefan
