Hello,
The situation: file is added and committed to a branch, then the same
revision
is merged into trunk. After that, the range of revisions are merged from
trunk
back to the same branch which results in a tree conflict on the added file.
My
understanding of svn:mergeinfo isn't consistent with this behaviour as, to
my
mind, trunk 'knows' that the file originated from the branch and branch
'knows' that
the revision which resulted in the addition of a file had already been
merged
into trunk.
Below is the described scenario reproduced on SVN server v1.6.9 and client
v1.6.12
Exists:
/trunk
> svn copy /trunk /branches/branch -m "created branch"
> svn co /
> cd branches/branch
> echo "test" > newfile
> svn add newfile
> A newfile
> svn commit -m "adding newfile"
> Adding branch/newfile
> Transmitting file data .
> Committed revision 10.
> cd ../../trunk
> svn merge -c 10 /branches/branch
> --- Merging r10 into '.':
> A test
> svn commit -m "merged r10 into trunk"
> Sending src
> Adding src/test
>
> Committed revision 11.
> svn pg svn:mergeinfo .
> /branches/branch:10
> cd ../branches/branch
> svn pg svn:mergeinfo .
> svn log --stop-on-copy
> ------------------------------------------------------------------------
> r9 | dm3 | 2010-09-07 11:12:55 +0300 (Tue, 07 Sep 2010) | 1 line
>
> created branch
> ------------------------------------------------------------------------
> svn merge -r 9:HEAD /trunk
> --- Merging r9 through r11 into '.':
> C test
> Summary of conflicts:
> Tree conflicts: 1
> sst
> M .
> C test
> > local add, incoming add upon merge
I would be grateful if you could point me to the explanation of why SVN
behaves
this way under the given circumstances.
Received on 2010-09-07 11:20:30 CEST