RE: Merge tracking bug - inherited merge-range

Now that I have a 1.7-alpha client, I gave this scenario I posted last month another try, and it works fine. Not a problem for 1.7.

-Steve

From: Varnau, Steve (Neoview)
Sent: Monday, May 09, 2011 6:06 PM
To: users_at_subversion.apache.org
Cc: Brackett, Faye
Subject: Merge tracking bug - inherited merge-range

Greetings,

I have a merge tracking bug to report. It seems like there are a lot of steps to re-produce it, but we discovered this in the real world, and it took a long while to figure out what was going on and to re-produce it.

We are running 1.6.15 clients. We have lots of branching, and unfortunately svn:mergeinfo at multiple levels. This bug apparently only shows up if you merge two levels of directory that have new mergeinfo properties. The lower level directory does not get updated correctly and causes duplicate merge conflicts later.

Yes, I know "best practice" says to merge only at the top-level, but in a large project, those merge-tracking properties can grow like weeds.

The example steps below to reproduce use multiple branches just to produce the mergeinfo at multiple directory levels. There might be a simpler way to reproduce it.

I did not find anything in the issue tracker, and I have not tried this with 1.6.16 or with pre-release 1.7.

-Steve

# create sub-directory tree
$ svn co file:///c:/temp/svn-test/trunk<file:///c:\temp\svn-test\trunk> trunk-wc
$ cd trunk-wc/
$ svn mkdir subA
$ svn mkdir subA/subB
$ svn ci -m "need 2 directories"
$ svn cp ^/trunk ^/branch/br1

# first branch adds some content
$ cd ..
$ svn co file:///c:/temp/svn-test/branch/br1<file:///c:\temp\svn-test\branch\br1> br1-wc
$ cd br1-wc/subA
$ touch foo
$ touch subB/bar
$ svn add foo subB/bar
$ svn ci -m "br1 adds"

# second project branch picks up the directories before project 1 delivers
# third and forth start later
$ cd ../..
$ cd trunk-wc/
$ svn cp ^/trunk ^/branch/br2 -m "victim project"
$ svn merge --reintegrate ^/branch/br1
$ svn ci -m ""
$ svn cp ^/trunk ^/branch/br3 -m "foo project"
$ svn cp ^/trunk ^/branch/br4 -m "bar project"

# three projects working concurrently, project 3 & 4 make changes
$ cd ..
$ svn co file:///c:/temp/svn-test/branch/br2<file:///c:\temp\svn-test\branch\br2> br2-wc
$ svn co file:///c:/temp/svn-test/branch/br3<file:///c:\temp\svn-test\branch\br3> br3-wc
$ svn co file:///c:/temp/svn-test/branch/br4<file:///c:\temp\svn-test\branch\br4> br4-wc
$ cd br3-wc/subA/
$ echo "change" > foo
$ svn ci -m ""
$ cd ../../br4-wc/subA/subB/
$ echo "change" > bar
$ svn ci -m ""

# project 2 first synchs up the changes from br1
$ cd ../../../br2-wc/
$ svn merge ^/trunk
$ svn ci -m "synch 1"
$ svn up
At revision 88.

# project 3 & 4 each deliver content AND incidentally add svn:merginfo properties to subA & subB
$ cd ../trunk-wc/subA/subB/
$ svn up
$ svn merge --reintegrate ^/branch/br4/subA/subB
$ svn ci -m "deliver bar"
Committed revision 89.
$ cd ..
$ svn up
$ svn merge --reintegrate ^/branch/br3/subA
$ svn ci -m "deliver foo"
Committed revision 90.

# project 2 synchs up again, including svn:mergeinfo
$ cd ../../br2-wc/
$ svn merge ^/trunk
--- Merging r88 through r90 into '.':
U subA\foo
U subA\subB\bar
U subA\subB
U subA
# at this point mergeinfo is correct for subA, but not for subB

# The content looks okay, so we check in and try another synch merge
# Even though nothing changed on trunk, we get duplicate merge conflict
$ svn ci -m "synch 2"
$ svn up
At revision 91.
$ svn merge ^/trunk

--- Merging r82 through r87 into 'subA\subB':
   C subA\subB\bar
Summary of conflicts:
  Tree conflicts: 1
Received on 2011-06-18 00:54:47 CEST