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.
