Hi Stefan,
thanks for taking the time to write that tool.
I've scheduled a time-slot to check this out/test on our side.
Unfortunately, our current project plan doesn't provide enough free time
to check this out in the next 2-4 weeks. I'll get back to you
immediately once I got the time to work on this task.
If you have any time requirements/considerations on your side which
would require/benefit from earlier feedback, pls let me know.
Regards,
Stefan
> On Tue, Feb 24, 2015 at 6:27 PM, Bert Huijben <bert_at_qqmail.nl
> <mailto:bert_at_qqmail.nl>> wrote:
>
> I see a few questions, that our merge experts over here on the
> dev@ list might have a better answer for than I have.
>
>
> Hi Stefan,
>
> If you have a working build environment for Subversion,
> you might have a look at this branch:
>
> https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer
>
> It provides a new tool that you might find useful:
>
> ./tools/client-side/svn-mergeinfo-normalizer/svn-mergeinfo-normalizer
>
> which allows you to analyse and reduce the mergeinfo in a working copy.
> It also tells you which mergeinfo cannot be elided and _why_.
>
> svn-mergeinfo-normalizer analyse /path/to/working/copy
> svn-mergeinfo-normalizer normalize /path/to/working/copy
> svn-mergeinfo-normalizer analyse /path/to/working/copy
> svn-mergeinfo-normalizer clear-obsoletes /path/to/working/copy
> svn-mergeinfo-normalizer analyse /path/to/working/copy
> svn-mergeinfo-normalizer combine-ranges /path/to/working/copy
> svn-mergeinfo-normalizer analyse /path/to/working/copy
>
> CAVEAT: This tool has not been reviewed and thoroughly tested.
> You should only commit changes that you have verified to be correct.
>
> Please let us know what your results were.
>
> -- Stefan^2.
>
>
> *From:*Stefan Hett [mailto:stefan_at_egosoft.com
> <mailto:stefan_at_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: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-03-26 14:21:39 CET