[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts on merging into a branch

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Fri, 7 May 2010 17:15:25 +1000

On Thu, May 6, 2010 at 4:16 PM, Matthias Weyh <m.weyh_at_technisat.de> wrote:
> Hello,
>
> Since I did not get any responses to my question on the users group and
> this might be a bug I am reposting this to the dev user group.
>
> I am looking forward to your answers.
>
> Thanks,
> Matthias
>
> -----Ursprüngliche Nachricht-----
> Von: Matthias Weyh [mailto:m.weyh_at_technisat.de]
> Gesendet: Donnerstag, 29. April 2010 08:26
> An: users_at_subversion.apache.org
> Betreff: Tree conflicts on merging into a branch
>
> Hello,
>
> I have seen an issue with subversion in which tree conflicts are being
> produced when creating a branch from a working copy in which not all
> files are at the same revision. This is happening when trying to merge
> changes into this branch.
>
> Please refer to the following sequence. Is this supposed to be happening
> in this way? I do not exactly understand what causes the tree conflicts.
> Shouldn't there at least be a warning on trying to copy from a working
> copy with mixed revisions?
>

<snipped />

> test>svn ci -m "stuff"
> Adding         d1
> Adding         d1\f1.txt
> Adding         d2
> Adding         d2\f1.txt
> Adding         d3
> Adding         d3\f1.txt
> Transmitting file data ...
> Committed revision 2.

At this point, the root of the working copy is still r1 - committing
children of a directory does not bump the revision of the parent
directory. You need to explicitly run an 'svn update .' here before
the copy.

> test>svn copy . https://localhost/svn/test/branches/b1 -m "created b1"
>
> Committed revision 3.

As a result, this copy causes the following 'copy-from' information:
 - b1 is copied from trunk @ r1
 - d1, d2, and d3 are all copied from trunk @ r2

> test>svn merge https://localhost/svn/test/trunk
> --- Merging r2 through r4 into '.':
> A    d1_r
> A    d1_r\f1.txt
>   C d2
>   C d3
> Summary of conflicts:
>  Tree conflicts: 2

And so here, because b1 was copied from trunk @ r1, then everything
from r2 up to HEAD is 'eligible' to be merged into the branch. This
can be confirmed with 'svn mergeinfo --show-revs eligible'.

> D:\repositories\test>svn status -v
>  M               4        3 weyh         .
>                 4        3 weyh         d1
>                 4        2 weyh         d1\f1.txt
>      C          4        3 weyh         d2
>      >   local add, incoming add upon merge
>                 4        2 weyh         d2\f1.txt
> A  +             -       ?   ?           d1_r
> A  +             -        2 weyh         d1_r\f1.txt
>      C          4        3 weyh         d3
>      >   local add, incoming add upon merge
>                 4        2 weyh         d3\f1.txt

Thats probably the best I can do for an explanation. As to whether its
a bug or by design, I can't help you. But, on the surface, it sounds
as though creating branches from mixed-revision working copies will
cause problems with merging.

Regards,
Daniel B.
Received on 2010-05-07 09:16:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.