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