RE: Merge tracking bug - inherited merge-range
From: Varnau, Steve (Neoview) <steve.varnau_at_hp.com>
Date: Fri, 17 Jun 2011 22:52:39 +0000
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.
From: Varnau, Steve (Neoview)
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.
# create sub-directory tree
# first branch adds some content
# second project branch picks up the directories before project 1 delivers
# three projects working concurrently, project 3 & 4 make changes
# project 2 first synchs up the changes from br1
# project 3 & 4 each deliver content AND incidentally add svn:merginfo properties to subA & subB
# project 2 synchs up again, including svn:mergeinfo
# The content looks okay, so we check in and try another synch merge
--- Merging r82 through r87 into 'subA\subB':
This is an archived mail posted to the Subversion Users mailing list.