Stefan Sperling wrote:
> 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, this works well, thanks very much for the suggestion. I have
also just come across this blog which gives more insight and limitations
into what you mentioned:
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
Personally, I think the svn documentation needs to have some more
information on bidirectional merging, tree conflicts when merging and
the background information given in that blog.
William
Received on 2009-12-30 15:53:15 CET