I see a few questions, that our merge experts over here on the dev@ list might
have a better answer for than I have.
Bert
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: dinsdag 24 februari 2015 11:28
To: Bert Huijben; 'subversion'
Subject: Re: inconsistency between mergeinfo records
Hi Bert,
thanks. That mostly does explain the current behavior to me.
>From a user's point of view I however find this difference in recorded
>mergeinfos quite problematic. While certainly both cases represent the same
>logical merge structure:
case 1:
svn:mergeinfo for /B: /A:2-5
case 2:
svn:mergeinfo for /B: /A:2-5
svn:mergeinfo for /B/test.txt /A/test.txt:3
The redundant? mergeinfo of /B/test.txt is causing quite some issues for us.
It's true, that when I directly reintegrate B back into A, A would not record
the "redundant" mergeinfo for A/test.txt. But if I create another branch from B
(let's say C) and reintegrate this back into A, the mergeinfo (assuming, didn't
test!) will be kept in /A/test.txt - ending up with mergeinfos on a file.
When I never reintegrate B back into A, this mergeinfo in test.txt wil stay
forever, having an accumulating effect on the number of files containing
mergeinfos over the time...
In our productive environment this now resulted in hundreds of files having
retrieved this kind of redundant mergeinfos:
/X4/branches/AI2.0/XU_Shader/XU_ALPHA8_LIT.FBPC:144773-145378
/X4/branches/August2009SDK/XU_Shader/XU_ALPHA8_LIT.FBPC:142562-142567
/X4/branches/NPCEventMonitor/XU_Shader/XU_ALPHA8_LIT.FBPC:145587-145636
/X4/branches/Stefan_Home/XU_Shader/XU_ALPHA8_LIT.FBPC:144592-145487
/X4/branches/Stefan_June_MS/XU_Shader/XU_ALPHA8_LIT.FBPC:144517-144570
/X4/branches/VS2008/XU_Shader/XU_ALPHA8_LIT.FBPC:145442,145447,145523-145524,145584,145648,145830,145854-145858,146407,146524,146575,146622,146723-146724,146727-146728,146730-146732
/X4/branches/martintest20091124/XU_Shader/XU_ALPHA8_LIT.FBPC:62718-142301
/X4/branches/outlines/XU_Shader/XU_ALPHA8_LIT.FBPC:146545-146677
/X4/branches/pointofinterest/XU_Shader/XU_ALPHA8_LIT.FBPC:146659-146830
/X4/branches/progressbar/XU_Shader/XU_ALPHA8_LIT.FBPC:146836-146938
/X4/branches/refcount/XU_Shader/XU_ALPHA8_LIT.FBPC:142627-142690
/X4/branches/refcount2/XU_Shader/XU_ALPHA8_LIT.FBPC:142509-142626
/X4/branches/tagging/XU_Shader/XU_ALPHA8_LIT.FBPC:146443-146531
/XRebirth/branches/64bitPart3/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:181658,181663
/XRebirth/branches/P1_Network/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:190755-191779
/XRebirth/branches/StefanWork/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:179568-179569
/XRebirth/branches/XR/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:184223,184357,184562,184564,184569,184575,184642,184656,184658,184664,184666,184668,184670,184676,184690,184692,184703,184706,184714,184718,184724,184726,184742,184748,184752,184754,184758,184765,184768,184770,184772,184795,184797,184805,184808,184819,184837-184838,184849-184850,184890,184906,184942,184944,184965,184969,184987,185001,185045,185051,185053,185064,185071,185073,185075,185088,185093,185096,185111,185120,185142,185148,185154,185161,185182,185231,185270,185273,185301,185330,185332,185348,185357,185372,185374,185406,185426,185455,185461,185511,185526,185546,185559,185562,185566,185579,185606,185645,185669,185672,185674,185676,185678,185680,185689,185704,185738,185745,185749,185758,185797,185890,185893,185896,185898,185900,185909,185949,185993,186001,186007,186020,186031,186080,186082,186106,186108,186122-186123,186127,186134-186137,186166,186169,186172,186174,186181,186183,186186,186210,186214,186218,186225,186234
,186239,186248-186249,186259,186265,186269,186272,186286,186290,186302,186318,186334,186344,186357,186360-186361,186380,186382,186405,186420,186447,186456-186458,186466,186471,186506,186511,186543,186561,186566,186583-186584,186605,186607,186609,186614,186616,186620,186623,186635,186644,186646,186661,186665,186668,186673,186683,186685,186693,186700,186702,186706,186714,186717,186727,188312,190701-190708,190953-190954,190967,191011,191021,191055,191057,191062,191104,191110,191113,191125,191171,191181,191183,191185,191238,191249,191251,191253,191260,191302,191324,191326,191352,191366-191367,191407-191408,191412,191429,191471,191494,191513,191524,191532,191537,191540,191554,191606,191636,191656,191660,191675,191695,191701,191706,191709,191712,191714,191735,191740-191741,191782,191794,191809,191812,191834,191846,191856,191860,191882
/XRebirth/branches/XR_UIModding/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:188213-190700
/XRebirth/branches/XR_WareExchange/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:187945-188311
/XRebirth/branches/editbox/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:180159-180481
/XRebirth/branches/nexttarget/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:179611-180069
/XRebirth/branches/performance/data/shaderfx/high/XU_ALPHA8_LIT.FBPC:179685,179688,179811,179911
Using TortoiseSVN as our main client, this makes a lot of cases quite
inconvenient:
- showing the overview when committing merged changes, is hard, because this
brings up a list of hundreds of files with the actual changed files being
somewhere in-between
- logs are cluttered with mergeinfo changes, so it's quite hard to find the
actual changes in a revision
- committing changes is unnecessarily slowed-down because all mergeinfo changes
are transferred one-by-one
- I guess other SVN-operations are slowed-down as well, because the mergeinfos
are not stored only in one single mergeinfo-property...
Do u have any suggestion for us to improve our workflow? Wouldn't it be
reasonable to change the behavior of the --record-only merge, so that it does
not store these "redundant" mergeinfos in the first place?
Regards,
Stefan
I haven’t looked at the full details, but actual merges only store mergeinfo of
what is actually merged (includes unaffected tree filtering, filtering what is
already merged, etc.). A record only merge is a tool to just register as merged
the affected target without further processing. It is primarily used to block
further merges, or unblock something that wasn’t really merged.
So totally different mergeinfo is fully expected.
Does this answer your question, or did either of your operations record wrong
mergeinfo?
Bert
Sent from Windows Mail
From: Stefan Hett <mailto:ste...@egosoft.com>
Sent: Monday, February 23, 2015 8:30 AM
To: 'subversion' <mailto:us...@subversion.apache.org>
Another user (Sergey Azarkevich) actually pointed me to an interesting fact:
C:\test\test2checkout>svn merge file:///C:/test/test2/A
<file:///C:\test\test2\A> B --record-only
--- Recording mergeinfo for merge of r2 through r5 into 'B':
...
C:\test\test2checkout>svn merge file:///C:/test/test2/A
<file:///C:\test\test2\A> B
--- Merging r3 through r5 into 'B':
...
Using explicit range of revisions same as for --record-only lead to equal
modifications in wc:
C:\test\test2checkout>svn merge file:///C:/test/test2/A
<file:///C:\test\test2\A> B -r 2:5
--- Merging r3 through r5 into 'B':
Note the different ranges (r2-r5 vs. r3-r5 in the first two calls).
Maybe this sheds some light here?
Regards,
Stefan
> Looks like the batch-file got truncated by some clients/mail servers
> on the way --- here's the plain batch file content.
> Anyone having an idea what's going on here?
>
> REM create test repository
> mkdir C:\test
> cd /d C:\test
> mkdir test2
> svnadmin create test2
>
> REM check-out test repository
> mkdir test2checkout
> svn co file:///C:/test/test2 <file:///C:\test\test2> ./test2checkout
> cd test2checkout
>
> REM add initial structure
> mkdir A
> echo > A\test.txt
> svn add A
> svn commit -m test
>
> REM copy A to B
> svn cp A B
> svn commit -m test
>
> REM modify A/test.txt
> echo >> A\test.txt
> svn commit -m test
>
> REM cherry pick test.txt change and commit to B
> svn up
> svn merge -r 2:3 A/test.txt B/test.txt
> svn commit -m test
>
> REM modify A/test.txt again
> echo >> A\test.txt
> svn commit -m test
>
> REM do an auto merge of B
> svn up
> svn merge file:///C:/test/test2/A <file:///C:\test\test2\A> B
> REM This produces merge infos in B only
>
> REM alternative
> svn revert B -R
> svn merge file:///C:/test/test2/A <file:///C:\test\test2\A> B --record-only
> REM This produces merge infos in B AND B/test.txt
>
> Regards,
> Stefan
>> Hi,
>>
>> I'm wondering why there is a difference in how mergeinfos are
>> recorded based on whether the merge is done using --record-only or not.
>> To demonstrate the case, I've put together a repro-script (for
>> Windows - see attachment).
>>
>> My question is that why does the last step in the script produce
>> different merge-info properties:
>>
>> 1. svn merge file:///C:/test/test2/A <file:///C:\test\test2\A> B
>> This will produce mergeinfo in B
>>
>> 2. svn merge file:///C:/test/test2/A <file:///C:\test\test2\A> B
>> --record-only
>> This will produce mergeinfo in B and B/test.txt
>>
>> Looking through the web, the docu and the SVN buglist I couldn't find
>> any matching entry. Maybe someone can point me on where to look for
>> an explanation?
>>
>> I'm wondering especially because as an alternative to variation 2,
>> one might also follow variation 1 and then revert all changes (except
>> for the recorded mergeinfo B). Isn't the outcome then the same as
>> variation 2?
>>
>> Regards,
>> Stefan
>
