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:stefan_at_egosoft.com>
> *Sent:* Monday, February 23, 2015 8:30 AM
> *To:* 'subversion' <mailto:users_at_subversion.apache.org>
>
> Another user (Sergey Azarkevich) actually pointed me to an interesting
> fact:
> C:\test\test2checkout>svn merge 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 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 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 ./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 B
> > REM This produces merge infos in B only
> >
> > REM alternative
> > svn revert B -R
> > svn merge 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 B
> >> This will produce mergeinfo in B
> >>
> >> 2. svn merge 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
> >
>
Received on 2015-02-24 11:28:08 CET