On Tue, Feb 24, 2015 at 6:27 PM, Bert Huijben <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]
> *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 <stefan_at_egosoft.com>
> *Sent:* Monday, February 23, 2015 8:30 AM
> *To:* 'subversion' <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-24 22:23:18 CET