On Tue, Feb 24, 2015 at 6:27 PM, Bert Huijben <b...@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: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 <ste...@egosoft.com> > *Sent:* Monday, February 23, 2015 8:30 AM > *To:* 'subversion' <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 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 > > > > >
