I also expected step 4 to conflict, and I also don't get a conflict: [[[ 9,% ./new.sh ### Making a Greek Tree for import... ### Done.
### Importing it... Committed revision 1. ### Done. 9,% cd wc1/trunk/ 9,% $svn cp -q A A2 9,% $svn ci -q -m branch 9,% :>A/mu 9,% $svn ci -q -mrm A 9,% $svn up -q 9,% cp A2/mu A/mu 9,% $svn ci -q -madd A 9,% $svn up Updating '.': At revision 4. 9,% $svn merge -c 4 A A2 --- Recording mergeinfo for merge of r4 into 'A2': U A2 9,% $svn ci -mmerge Sending A2 Committed revision 5. 9,% cat A2/mu This is the file 'A/mu'. 9,% ]]] Maybe Johan can explain that :) Christoph Bartoschek wrote on Wed, Jun 22, 2011 at 21:25:29 +0200: > Hi, > > we have the following situation: > > 1. A branch is created from trunk. > 2. In trunk a line of code is added and commited as revision X > 3. The line is removed again and commited as revision X+1 > 4. In branch changeset X+1 is merged from trunk > 5. In branch changeset X is merged from trunk. > > The problem is now that in the branch the line is still there and > one gets no warning from subversion that something is wrong. > > Is this a bug in subversion? Why isn't there at least a merge > conflict for step 4? > > Christoph