subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hett <ste...@egosoft.com>
Subject Re: inconsistency between mergeinfo records
Date Thu, 26 Mar 2015 13:21:08 GMT
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@qqmail.nl 
> <mailto:bert@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@egosoft.com
>     <mailto:stefan@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@egosoft.com>
>         *Sent:* ‎Monday‎, ‎February‎ ‎23‎, ‎2015 ‎8‎:‎30‎ ‎AM
>         *To:* 'subversion' <mailto:users@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
>         >
>
>


Mime
View raw message