You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2015/02/24 18:27:07 UTC
RE: inconsistency between mergeinfo records
I see a few questions, that our merge experts over here on the dev@ list might have a better answer for than I have.
Bert
From: Stefan Hett [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 <ma...@egosoft.com>
Sent: Monday, February 23, 2015 8:30 AM
To: 'subversion' <ma...@subversion.apache.org>
Another user (Sergey Azarkevich) actually pointed me to an interesting fact:
C:\test\test2checkout>svn merge file:///C:/test/test2/A <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 <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 <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 <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 <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 <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 <file:///C:\test\test2\A> B
>> This will produce mergeinfo in B
>>
>> 2. svn merge file:///C:/test/test2/A <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
>
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
Hi Julian,
thanks for the explanation. I'll make a note on our recorded issue here
and will see to update our scripts/workflow to cope for this updated
information on how --record-only behaves.
Regards,
Stefan
> Bert forwarded to dev@ from Stefan Hett:
>> Bert wrote:
>>> 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?
>> 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...
>> [...]
>> 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?
>
> I think it would be sensible if --record-only did exactly what a normal merge does, except not record the final mergeinfo. However, that is not completely possible. When a merge adds a file or directory, it may add subtree mergeinfo on that file/dir (in other words, mergeinfo that differs from the mergeinfo it would otherwise inherit). In a record-only merge, the file/dir would not be added, and so there is nowhere to add the corresponding mergeinfo. That is a limitation of our mergeinfo storage design.
>
> I am thinking about a future redesign of mergeinfo, mainly to support move tracking. Rather than try to improve the current design and implementation further, I will bear this in mind as one of the properties the new merge tracking should have.
>
> - Julian
>
Re: inconsistency between mergeinfo records
Posted by Julian Foad <ju...@btopenworld.com>.
Bert forwarded to dev@ from Stefan Hett:
> Bert wrote:
>> 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?
>
> 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...
> [...]
> 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?
I think it would be sensible if --record-only did exactly what a normal merge does, except not record the final mergeinfo. However, that is not completely possible. When a merge adds a file or directory, it may add subtree mergeinfo on that file/dir (in other words, mergeinfo that differs from the mergeinfo it would otherwise inherit). In a record-only merge, the file/dir would not be added, and so there is nowhere to add the corresponding mergeinfo. That is a limitation of our mergeinfo storage design.
I am thinking about a future redesign of mergeinfo, mainly to support move tracking. Rather than try to improve the current design and implementation further, I will bear this in mind as one of the properties the new merge tracking should have.
- Julian
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
Hi Stefan^2,
>
> Hi Stefan,
>
> First of all, thank you for the detailed feedback! It is very helpful.
>
> I spent the last two weeks refactoring and reworking the tool. The
> main changes:
> * explicit --verbose mode, much quieter without it
> * progress output
> * only one common 'normalize' sub-command; actions selected by options
> * 'analyze' and the new 'remove-branches' sub-command use the same code
> as 'normalize' and should therefore be consistent
> * faster processing with large number of branches and / or high
> latency networks
I was following ur commits on the mailing list and just tried out the
latest version. Great work there. The changes done make this tool so
much more usable compared to the old version. I also sent you the
regenerated logs (based on the same branch/rev I used for the old tool)
just in case comparing the different outputs is useful to you.
One small note: While I do understand the reasoning for the different
default switches for analyze/normalize, initially I was surprised a bit
that while normalize only ran with --remove-redundant, analyze created
the output for --remove-redundant/--combine-ranges/--remove-obsoletes.
I would have expected that both commands consistently use the
--remove-redundant option only, unless specified.
> I must also admit that the old 'normalize' command has a flaw that
> would result
> in the removal of sub-tree mergeinfo that was NOT redundant. The 'analyze'
> output was correct, though, and the problem only manifested when sub-tree
> mergeinfo could be completely removed. To check whether you have been
> affected,
> do the following:
>
> * c/o the revision before any m/i changes were committed.
> * run the latest tool 'normalize --remove-redundant --remove-obsoletes'
> * run 'svn pg svn:mergeinfo -R /path/to/working/copy --xml | grep
> "path= " '
> to get a list of nodes that still have mergeinfo on them
> * run the same 'svn pg ...' command on the committed changes produced by
> the old tool
> * compare the output, looking for m/i that only the old tool removed
> * if need be, manually fix them
Thanks for letting me know. I ran the tests and verified I didn't run
into this issue here.
> Also it'd be good to add a more automated "one-step" command to
> simplify the usage even further. So a user/admin could simply
> start the tool (for instance svn-mergeinfo-normalizer
> clean-up-mergeinfo [path] -drop-obsolete-branches) which would
> more or less equal running the tool several times in the following
> sequence:
> svn-mergeinfo-normalizer.exe clear-obsoletes [path]
> svn-mergeinfo-normalizer.exe normalize [path]
> svn-mergeinfo-normalizer.exe combine-ranges [path]
> svn-mergeinfo-normalizer.exe analyse [path] -stats
>
> (where I'd envision the -stats param for the analyse command would
> print out a summary of how many remaining mergeinfos could not be
> normalized (if any) and pointing the user to run the full analysis
> step to get a more detailed output).
>
>
> Try the new command structure and options. Is that roughly what you
> had in mind?
Absolutely. Feels right to me (with the addition of the note mentioned
above).
> For the long term I hope that the functionality provided by this
> tool would become obsolete and the issues for which you have to
> use this tool are dealt with directly in the SVN core so these
> would not surface at all anymore (aka: no need to normalize
> mergeinfos manually).
>
> Newer releases of SVN try to elide sub-tree mergeinfo as they go.
> However, they can't be as thourough as this tool (for performance
> reasons) and will not "fix" old mergeinfo. The one thing that it will
> probably never do is remove mergeinfo for deleted branches because
> that is a potentially destructive operation and only o.k. if you never
> want to merge from those deleted branches again (99.9% of users).
Fully agreed with the dropping of branch-mergeinfos (in the current
merge(info) design of SVN).
Maybe an interim solution which might be worth considering is
integrating the other part of the normalizer's tool functionality into
the SVN-cleanup-command to some extend (or integrate it into the
svn-command somehow).
At least that way it would be easier accessible to a broader audience
and also be more likely be integrated in 3rd-party tools (like TSVN, etc.).
> The other thing might be to add some stat-output to normalize /
> combine-ranges / clear-obsoletes to report how many mergeinfo
> entries could be normalized, or how many obsolete paths were removed.
> Since the commands can take a few minutes to run, some kind of
> "progress output" might also be useful, so the user knows the
> process did not deadlock or ran into an endless loop.
>
>
> There is progress info now while the log gets downloaded and for the
> 'normalize' command processing when not in --verbose mode.
I also see the processing info when running normalize -v. Honestly I
find this quite useful, but if u intended it to be not that way, then I
guess I've to report it's bugged here (in this case voting for keeping
the bug though :) ).
Btw. Your idea to add a command to specify which branches are to be
dropped when running the remove-obsoletes command: This is actually
something I'd also use once it's available. :-) So looking forward to it
being added.
Once more: thanks all your work.
Regards,
Stefan
Re: inconsistency between mergeinfo records
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Jun 25, 2015 at 3:29 PM, Stefan Hett <st...@egosoft.com> wrote:
> Hi,
>
> as promised, answering the remaining questions now:
>
Hi Stefan,
First of all, thank you for the detailed feedback! It is very helpful.
I spent the last two weeks refactoring and reworking the tool. The main
changes:
* explicit --verbose mode, much quieter without it
* progress output
* only one common 'normalize' sub-command; actions selected by options
* 'analyze' and the new 'remove-branches' sub-command use the same code
as 'normalize' and should therefore be consistent
* faster processing with large number of branches and / or high latency
networks
I must also admit that the old 'normalize' command has a flaw that would
result
in the removal of sub-tree mergeinfo that was NOT redundant. The 'analyze'
output was correct, though, and the problem only manifested when sub-tree
mergeinfo could be completely removed. To check whether you have been
affected,
do the following:
* c/o the revision before any m/i changes were committed.
* run the latest tool 'normalize --remove-redundant --remove-obsoletes'
* run 'svn pg svn:mergeinfo -R /path/to/working/copy --xml | grep "path= " '
to get a list of nodes that still have mergeinfo on them
* run the same 'svn pg ...' command on the committed changes produced by
the old tool
* compare the output, looking for m/i that only the old tool removed
* if need be, manually fix them
[...]
>
>
>> If you have any time requirements/considerations on your side which
>> would require/benefit from earlier feedback, pls let me know.
>>
>
> Right now, we are all working towards the 1.9 RC. Feedback
> in May or June would be nice.
>
> The key question that I like to see answered is "Does the
> tool do something useful?" For instance, it might become
> ineffective in complex setups, we might need to add detection
> of "mismatched" branches etc. We might also end up with
> mergeinfo that is technically smaller but neither faster to
> process nor easier to understand.
>
> Overall I think this is a really great tool and is really valuable to
> administrators who have been running larger instances over a longer period
> of time.
>
> Initially the output of the analysis-log is kinda bloated. In my initial
> run the output produces a 2MB log-file. After reducing the amount of
> mergeinfo records (using normalization and dropping merginfos from obsolete
> branches) the output is quite good/reasonable. Some kind of documentation
> explaining the different output statements mean and what the admin/user
> could do about it would be helpful though I think.
>
The commands have comprehensive documention now.
The "what to do about it" part is yet to be addressed.
> Also it'd be good to add a more automated "one-step" command to simplify
> the usage even further. So a user/admin could simply start the tool (for
> instance svn-mergeinfo-normalizer clean-up-mergeinfo [path]
> -drop-obsolete-branches) which would more or less equal running the tool
> several times in the following sequence:
> svn-mergeinfo-normalizer.exe clear-obsoletes [path]
> svn-mergeinfo-normalizer.exe normalize [path]
> svn-mergeinfo-normalizer.exe combine-ranges [path]
> svn-mergeinfo-normalizer.exe analyse [path] -stats
>
> (where I'd envision the -stats param for the analyse command would print
> out a summary of how many remaining mergeinfos could not be normalized (if
> any) and pointing the user to run the full analysis step to get a more
> detailed output).
>
Try the new command structure and options. Is that roughly what you had in
mind?
> For the long term I hope that the functionality provided by this tool
> would become obsolete and the issues for which you have to use this tool
> are dealt with directly in the SVN core so these would not surface at all
> anymore (aka: no need to normalize mergeinfos manually).
>
Newer releases of SVN try to elide sub-tree mergeinfo as they go.
However, they can't be as thourough as this tool (for performance
reasons) and will not "fix" old mergeinfo. The one thing that it will
probably never do is remove mergeinfo for deleted branches because
that is a potentially destructive operation and only o.k. if you never
want to merge from those deleted branches again (99.9% of users).
A completely rewritten branching and mergeing logic may solve
the problem on a fundamental level.
> So, there are the things that I'd love to get some feedback on:
>
> * Does the tool work at all (no crashes, nothing obviously stupid)?
>
> I experienced no crashes and the output was quite clear to me (after
> facing the initial quite bloated analysis output ).
>
> * Is the result of each reduction stage correct (as far as one can tell)?
>
> Already pointed out a few cases in my other replies. Will start a new
> thread to keep this with the further remaining cases I think I found.
>
> * Is the tool feedback intelligible? How could that be improved?
>
> As suggested above some means to get a more statistical output especially
> for the initial run might be helpful. The header information atm is already
> a good start, but maybe adding/cleaning-up the output a bit further to
> produce maybe some statistic log would be more useful for the first run.
>
> For instance atm the analysis-output reports the actual non-existing
> branches for each path the tool checks-out. In my case that's around 100
> branches for each of the 400 paths... -> over 40.000 lines of branch info.
> More useful would be a list at the top with branches being obsolete (it's
> implicit that all subdirectories into the branch is obsolete if the parent
> path is non-existand).
>
> With the added reporting of obsolete branches this is even worse now.
>
With the latest changes, 'analyze' will only show "offending" branches and
their
details by default. In --verbose mode, all branches are listed, but only
once per
node (plus a summary of remaining branches).
Also, there is now a summary listing of all deleted branches that were
encountered.
> The other thing might be to add some stat-output to normalize /
> combine-ranges / clear-obsoletes to report how many mergeinfo entries could
> be normalized, or how many obsolete paths were removed.
> Since the commands can take a few minutes to run, some kind of "progress
> output" might also be useful, so the user knows the process did not
> deadlock or ran into an endless loop.
>
There is progress info now while the log gets downloaded and for the
'normalize' command processing when not in --verbose mode.
> * How effective is each stage / mergeinfo reduction command?
> * How often does it completely elide sub-tree mergeinfo?
> * What typical scenarios prevented sub-tree mergeinfo elision?
>
> I guess this was already answered by sending you the log files.
>
Yup. In particular, combining ranges was more effective than expected.
> Up to here, you don't need to commit anything. If you are
> convinced that the tool works correctly, you may commit
> the results into some toy copy of your repository. Then the
> following would be interesting:
>
> * Are merges based on the reduced mergeinfo faster?
> * Do merges based on the reduced mergeinfo use less memory?
> * Any anomalies?
>
> I didn't spot any anomalies so far. With regards on performance and
> memory consumptions I can't provide any numbers. One common use-case which
> is now significantly faster though is to merge changes from one to the
> other branch, since it now only contains a few nodes with mergeinfos while
> before it had to commit up to 400 nodes changes... So this to us is a
> really significant improvement.
>
I think the tool will be shipped with 1.10. The only problematic part is
that
many vendors don't ship the tools but only core binaries. Maybe, it gets
merged into another tool.
-- Stefan^2.
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
Hi,
as promised, answering the remaining questions now:
> [...]
>
> If you have any time requirements/considerations on your side
> which would require/benefit from earlier feedback, pls let me know.
>
>
> Right now, we are all working towards the 1.9 RC. Feedback
> in May or June would be nice.
>
> The key question that I like to see answered is "Does the
> tool do something useful?" For instance, it might become
> ineffective in complex setups, we might need to add detection
> of "mismatched" branches etc. We might also end up with
> mergeinfo that is technically smaller but neither faster to
> process nor easier to understand.
Overall I think this is a really great tool and is really valuable to
administrators who have been running larger instances over a longer
period of time.
Initially the output of the analysis-log is kinda bloated. In my initial
run the output produces a 2MB log-file. After reducing the amount of
mergeinfo records (using normalization and dropping merginfos from
obsolete branches) the output is quite good/reasonable. Some kind of
documentation explaining the different output statements mean and what
the admin/user could do about it would be helpful though I think.
Also it'd be good to add a more automated "one-step" command to simplify
the usage even further. So a user/admin could simply start the tool (for
instance svn-mergeinfo-normalizer clean-up-mergeinfo [path]
-drop-obsolete-branches) which would more or less equal running the tool
several times in the following sequence:
svn-mergeinfo-normalizer.exe clear-obsoletes [path]
svn-mergeinfo-normalizer.exe normalize [path]
svn-mergeinfo-normalizer.exe combine-ranges [path]
svn-mergeinfo-normalizer.exe analyse [path] -stats
(where I'd envision the -stats param for the analyse command would print
out a summary of how many remaining mergeinfos could not be normalized
(if any) and pointing the user to run the full analysis step to get a
more detailed output).
For the long term I hope that the functionality provided by this tool
would become obsolete and the issues for which you have to use this tool
are dealt with directly in the SVN core so these would not surface at
all anymore (aka: no need to normalize mergeinfos manually).
> So, there are the things that I'd love to get some feedback on:
>
> * Does the tool work at all (no crashes, nothing obviously stupid)?
I experienced no crashes and the output was quite clear to me (after
facing the initial quite bloated analysis output ).
> * Is the result of each reduction stage correct (as far as one can tell)?
Already pointed out a few cases in my other replies. Will start a new
thread to keep this with the further remaining cases I think I found.
> * Is the tool feedback intelligible? How could that be improved?
As suggested above some means to get a more statistical output
especially for the initial run might be helpful. The header information
atm is already a good start, but maybe adding/cleaning-up the output a
bit further to produce maybe some statistic log would be more useful for
the first run.
For instance atm the analysis-output reports the actual non-existing
branches for each path the tool checks-out. In my case that's around 100
branches for each of the 400 paths... -> over 40.000 lines of branch
info. More useful would be a list at the top with branches being
obsolete (it's implicit that all subdirectories into the branch is
obsolete if the parent path is non-existand).
With the added reporting of obsolete branches this is even worse now.
The other thing might be to add some stat-output to normalize /
combine-ranges / clear-obsoletes to report how many mergeinfo entries
could be normalized, or how many obsolete paths were removed.
Since the commands can take a few minutes to run, some kind of "progress
output" might also be useful, so the user knows the process did not
deadlock or ran into an endless loop.
> * How effective is each stage / mergeinfo reduction command?
> * How often does it completely elide sub-tree mergeinfo?
> * What typical scenarios prevented sub-tree mergeinfo elision?
I guess this was already answered by sending you the log files.
> Up to here, you don't need to commit anything. If you are
> convinced that the tool works correctly, you may commit
> the results into some toy copy of your repository. Then the
> following would be interesting:
>
> * Are merges based on the reduced mergeinfo faster?
> * Do merges based on the reduced mergeinfo use less memory?
> * Any anomalies?
>
I didn't spot any anomalies so far. With regards on performance and
memory consumptions I can't provide any numbers. One common use-case
which is now significantly faster though is to merge changes from one to
the other branch, since it now only contains a few nodes with mergeinfos
while before it had to commit up to 400 nodes changes... So this to us
is a really significant improvement.
Regards,
Stefan
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
Hi,
>>> Building SVN now succeeds (120 warnings which I ignore for the time being
>>> though), but when trying to start the built svn.exe process, I'm facing the
>>> following error popup.
>>>
>>> ---------------------------
>>> svn.exe - Entry Point Not Found
>>> ---------------------------
>>> The procedure entry point svn__apr_hash_index_key could not be located in
>>> the dynamic link library libsvn_subr-1.dll.
>>> ---------------------------
>>> OK
>>> ---------------------------
>>>
>>> Would u have any hint for me what might be wrong?
>>> Checking-out the libsvn_subr-1.dll using Dependency Walker, I see that
>>> there's indeed to reference to svn__apr_hash_index_key in that dll.
>> I looks like the executable picked up the wrong SVN DLLs
>> (probably the ones installed on your system). You would
>> need to harvest the DLLs from the the binary output folder -
>> one per sub-directory, IIRC.
>>
>> Aside from that, I updated the svn-mergeinfo-normalizer
>> branch to catch up with the latest 1.9 code. So, it should
>> be able to e.g. use the upcoming 1.9 binaries at the moment.
> Maybe you can use the Makefile in
> http://svn.apache.org/repos/asf/subversion/trunk/tools/dev/windows-build,
> or parts of it. I'm using a variant of that myself. Running the "all1"
> target (nmake all1) builds the __ALL__ target with msbuild, and then
> the "package" target, which does this:
>
> [[[
> package:
> test -d $(SVNDIR)\$(CONFIG)\Subversion\tests\cmdline || mkdir
> $(SVNDIR)\$(CONFIG)\Subversion\tests\cmdline
> test -d $(TARGETDIR)\bin || mkdir $(TARGETDIR)\bin
> for %%i in (svn svnadmin svndumpfilter svnlook svnserve svnsync
> svnversion svnrdump svnmucc) do @$(CP)
> $(CONFIG)\subversion\%%i\%%i.exe $(TARGETDIR)\bin
> for %%i in (diff diff3 diff4) do @if exist
> $(CONFIG)\tools\diff\%%i.exe $(CP) $(CONFIG)\tools\diff\%%i.exe
> $(TARGETDIR)\bin
> $(CP) $(APRDIR)\$(CONFIG)/*.dll $(TARGETDIR)\bin
> $(CP) $(APRUTILDIR)\$(CONFIG)/*.dll $(TARGETDIR)\bin
> $(CP) $(APRICONVDIR)\$(CONFIG)/*.dll $(TARGETDIR)\bin
> $(CP) $(OPENSSLDIR)\out32dll/*.dll $(TARGETDIR)\bin
> for %%i in (client delta diff fs ra repos subr wc) do @$(CP)
> $(CONFIG)\subversion\libsvn_%%i\*.dll $(TARGETDIR)\bin
> ]]]
>
> (you need test.exe from unixutils or something similar for it to work)
>
> That copies all exe's and dll's nicely to the dist\bin subdirectory
> (which you can then put in your PATH (or cd into it) to test it).
Thanks to the both of you, it's now working and am running the first
tests with the normalizer-tool. Indeed it was a DLL-mismatch.
Also thanks for updating the branch @Stefan^2.
Regards,
Stefan
Re: inconsistency between mergeinfo records
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jun 23, 2015 at 3:18 PM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
> On Tue, Jun 23, 2015 at 2:33 PM, Stefan Hett <st...@egosoft.com> wrote:
>>
>> Hi Stefan^2,
>>
>> On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett <st...@egosoft.com> wrote:
>>>
>>> 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.
>>
>>
>> No worries. The tool is intended to be released with 1.10,
>> so there is no rush.
>>
>> Finally I got along setting-up (what I think is) a working build
>> environment for the branch.
>
>
> Excellent, thank you!
>
>>
>> Building SVN now succeeds (120 warnings which I ignore for the time being
>> though), but when trying to start the built svn.exe process, I'm facing the
>> following error popup.
>>
>> ---------------------------
>> svn.exe - Entry Point Not Found
>> ---------------------------
>> The procedure entry point svn__apr_hash_index_key could not be located in
>> the dynamic link library libsvn_subr-1.dll.
>> ---------------------------
>> OK
>> ---------------------------
>>
>> Would u have any hint for me what might be wrong?
>> Checking-out the libsvn_subr-1.dll using Dependency Walker, I see that
>> there's indeed to reference to svn__apr_hash_index_key in that dll.
>
>
> I looks like the executable picked up the wrong SVN DLLs
> (probably the ones installed on your system). You would
> need to harvest the DLLs from the the binary output folder -
> one per sub-directory, IIRC.
>
> Aside from that, I updated the svn-mergeinfo-normalizer
> branch to catch up with the latest 1.9 code. So, it should
> be able to e.g. use the upcoming 1.9 binaries at the moment.
Maybe you can use the Makefile in
http://svn.apache.org/repos/asf/subversion/trunk/tools/dev/windows-build,
or parts of it. I'm using a variant of that myself. Running the "all1"
target (nmake all1) builds the __ALL__ target with msbuild, and then
the "package" target, which does this:
[[[
package:
test -d $(SVNDIR)\$(CONFIG)\Subversion\tests\cmdline || mkdir
$(SVNDIR)\$(CONFIG)\Subversion\tests\cmdline
test -d $(TARGETDIR)\bin || mkdir $(TARGETDIR)\bin
for %%i in (svn svnadmin svndumpfilter svnlook svnserve svnsync
svnversion svnrdump svnmucc) do @$(CP)
$(CONFIG)\subversion\%%i\%%i.exe $(TARGETDIR)\bin
for %%i in (diff diff3 diff4) do @if exist
$(CONFIG)\tools\diff\%%i.exe $(CP) $(CONFIG)\tools\diff\%%i.exe
$(TARGETDIR)\bin
$(CP) $(APRDIR)\$(CONFIG)/*.dll $(TARGETDIR)\bin
$(CP) $(APRUTILDIR)\$(CONFIG)/*.dll $(TARGETDIR)\bin
$(CP) $(APRICONVDIR)\$(CONFIG)/*.dll $(TARGETDIR)\bin
$(CP) $(OPENSSLDIR)\out32dll/*.dll $(TARGETDIR)\bin
for %%i in (client delta diff fs ra repos subr wc) do @$(CP)
$(CONFIG)\subversion\libsvn_%%i\*.dll $(TARGETDIR)\bin
]]]
(you need test.exe from unixutils or something similar for it to work)
That copies all exe's and dll's nicely to the dist\bin subdirectory
(which you can then put in your PATH (or cd into it) to test it).
--
Johan
Re: inconsistency between mergeinfo records
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Jun 23, 2015 at 2:33 PM, Stefan Hett <st...@egosoft.com> wrote:
> Hi Stefan^2,
>
> On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett <st...@egosoft.com> wrote:
>
>> 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.
>>
>
> No worries. The tool is intended to be released with 1.10,
> so there is no rush.
>
> Finally I got along setting-up (what I think is) a working build
> environment for the branch.
>
Excellent, thank you!
> Building SVN now succeeds (120 warnings which I ignore for the time being
> though), but when trying to start the built svn.exe process, I'm facing the
> following error popup.
>
> ---------------------------
> svn.exe - Entry Point Not Found
> ---------------------------
> The procedure entry point svn__apr_hash_index_key could not be located in
> the dynamic link library libsvn_subr-1.dll.
> ---------------------------
> OK
> ---------------------------
>
> Would u have any hint for me what might be wrong?
> Checking-out the libsvn_subr-1.dll using Dependency Walker, I see that
> there's indeed to reference to svn__apr_hash_index_key in that dll.
>
I looks like the executable picked up the wrong SVN DLLs
(probably the ones installed on your system). You would
need to harvest the DLLs from the the binary output folder -
one per sub-directory, IIRC.
Aside from that, I updated the svn-mergeinfo-normalizer
branch to catch up with the latest 1.9 code. So, it should
be able to e.g. use the upcoming 1.9 binaries at the moment.
-- Stefan^2.
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
Hi Stefan^2,
> On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett <stefan@egosoft.com
> <ma...@egosoft.com>> wrote:
>
> 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.
>
>
> No worries. The tool is intended to be released with 1.10,
> so there is no rush.
Finally I got along setting-up (what I think is) a working build
environment for the branch.
Building SVN now succeeds (120 warnings which I ignore for the time
being though), but when trying to start the built svn.exe process, I'm
facing the following error popup.
---------------------------
svn.exe - Entry Point Not Found
---------------------------
The procedure entry point svn__apr_hash_index_key could not be located
in the dynamic link library libsvn_subr-1.dll.
---------------------------
OK
---------------------------
Would u have any hint for me what might be wrong?
Checking-out the libsvn_subr-1.dll using Dependency Walker, I see that
there's indeed to reference to svn__apr_hash_index_key in that dll.
Regards,
Stefan
Re: inconsistency between mergeinfo records
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett <st...@egosoft.com> wrote:
> 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.
>
No worries. The tool is intended to be released with 1.10,
so there is no rush.
> If you have any time requirements/considerations on your side which would
> require/benefit from earlier feedback, pls let me know.
>
Right now, we are all working towards the 1.9 RC. Feedback
in May or June would be nice.
The key question that I like to see answered is "Does the
tool do something useful?" For instance, it might become
ineffective in complex setups, we might need to add detection
of "mismatched" branches etc. We might also end up with
mergeinfo that is technically smaller but neither faster to
process nor easier to understand.
So, there are the things that I'd love to get some feedback on:
* Does the tool work at all (no crashes, nothing obviously stupid)?
* Is the result of each reduction stage correct (as far as one can tell)?
* Is the tool feedback intelligible? How could that be improved?
* How effective is each stage / mergeinfo reduction command?
* How often does it completely elide sub-tree mergeinfo?
* What typical scenarios prevented sub-tree mergeinfo elision?
Up to here, you don't need to commit anything. If you are
convinced that the tool works correctly, you may commit
the results into some toy copy of your repository. Then the
following would be interesting:
* Are merges based on the reduced mergeinfo faster?
* Do merges based on the reduced mergeinfo use less memory?
* Any anomalies?
-- Stefan^2.
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
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
> <ma...@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
> <ma...@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 <ma...@egosoft.com>
> *Sent:* Monday, February 23, 2015 8:30 AM
> *To:* 'subversion' <ma...@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
> >
>
>
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
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.
>
> [...]
>
> I gave the normalizer a first run and using it I was able to
> reduce our record of mergeinfos quite significantly without too
> much manual work. So alltogether I'd consider this a really useful
> tool.
> I sent you the logs per PM so you can take a look at all the
> details yourself (some of the information contained in the logs I
> do not want to make publicly available on the mailing list and
> it's quite some large logs (several MB)).
>
>
> Those logs are really helpful. I've already found a number of
> things that should be improved:
>
> * Branches should always be sorted by name
> * 'analyze' should also check whether obsolete branches can be elided.
> The 'normalize' step already does this.
I already tested ur committed changes from yesterday and see that these
changes have been added. Looks quite good and especially the sorted
branches helps reviewing the analyse-output IMO.
> [...]
>
> Note that running normalize at the beginning, could not remove any
> redundant mergeinfos at all, since there were always some
> revisions missing. However running the following sequence of
> commands first:
> 1. clear-obsoletes
> 2. combine-ranges
> 3. normalize
>
> Then was able to remove a significant amount of redundant
> mergeinfos (eliminating mergeinfos on over 100 files).
>
>
> I guess that was due to 'clear-obsoletes' removing lots of old merges
> from old branches where sub-tree mergeinfo could indeed not be elided.
> Once the extended analyze output is available as described above,
> you should be able to verify that hypothesis. That said, removing
> obsolete branches first is certainly a very efficient workflow.
That's correct and I could confirm it with the new analyze output to
actually having been the case here (also sent u the full output so u can
confirm --- sample for such a case was this one in the logs:
XR/clean_source_branch/data/shaderfx/medium/XU_effects_layered_unlit2_new.fx
(note that the same applies to basically all files/records in
data/shaderfx/xxx so this applied to the majority of the cases)
> [...]
>
> There were still some remaining records. These I managed to get
> rid of by manually merging the missing ranges.
>
>
> There are also a few genuine sub-tree merges that look like a sync
> with some vendor branch. Some might be replaced by svn:externals -
> which comes with a few restrictions as well as benefits.
I'm aware of the possibility to use svn:externals for cases like these.
The reason we ended-up with not using svn:externals in the cases shown
in the logs is mostly historically.
I introduced SVN in our company when I started here around 2007/2008
(migrating from MS VSS) at which time we started with SVN 1.5. As you
most likely know way better than me, while the svn-externals
concept/support evolved significantly over the past years (and I'd call
it quite a stable and useful feature in the current versions), there
were several issues/bugs/limitations regarding svn-externals in 1.5/1.6/1.7.
Since we had to invest a lot of work resolving some of these, we
ended-up not using svn-externals in the cases here. Also like you state
urself there are certain advantages here, which in our case overweight
the disadvantages atm.
Regards,
Stefan
Re: inconsistency between mergeinfo records
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Jun 24, 2015 at 10:21 AM, Stefan Hett <st...@egosoft.com> wrote:
> Hi Stefan^2,
>
> 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.
>>
> [...]
>
> I gave the normalizer a first run and using it I was able to reduce our
> record of mergeinfos quite significantly without too much manual work. So
> alltogether I'd consider this a really useful tool.
> I sent you the logs per PM so you can take a look at all the details
> yourself (some of the information contained in the logs I do not want to
> make publicly available on the mailing list and it's quite some large logs
> (several MB)).
>
Those logs are really helpful. I've already found a number of
things that should be improved:
* Branches should always be sorted by name
* 'analyze' should also check whether obsolete branches can be elided.
The 'normalize' step already does this.
* 'analyze' should have a summary of all obsolete branches,
including their last change rev/timestamp and deletion rev/timestamp.
* There should be an new sub-command to remove a list of branches
from the mergeinfo. That gives users better control over this quite
destructive operation (throwing away mergeinfo as oposed to just
normalizing it).
> Note that running normalize at the beginning, could not remove any
> redundant mergeinfos at all, since there were always some revisions
> missing. However running the following sequence of commands first:
> 1. clear-obsoletes
> 2. combine-ranges
> 3. normalize
>
> Then was able to remove a significant amount of redundant mergeinfos
> (eliminating mergeinfos on over 100 files).
>
I guess that was due to 'clear-obsoletes' removing lots of old merges
from old branches where sub-tree mergeinfo could indeed not be elided.
Once the extended analyze output is available as described above,
you should be able to verify that hypothesis. That said, removing
obsolete branches first is certainly a very efficient workflow.
In your case, 'combine-ranges' has been surprisingly effective in reducing
the size of the mergeinfo representation (number of revision ranges is
down by >60%). As expected, it did not change the semantic contents.
IOW, has no effect on which sub-tree mergeinfo can be elided.
There were still some remaining records. These I managed to get rid of by
> manually merging the missing ranges.
>
There are also a few genuine sub-tree merges that look like a sync
with some vendor branch. Some might be replaced by svn:externals -
which comes with a few restrictions as well as benefits.
> One remaining case which couldn't be normalized automatically was on
> "/src/version_generator".
> Revision 190854 was recorded on root and on src but not on
> src/version_generator.
> 190854 was actually the creation of a branch (XRebirth/branches/XR_ogl).
>
Could you send me the output of 'svn log -v --xml -r190854' ?
That will tell me in detail what got changed.
The tool basically has the same information as that log output
and could certainly try hard to detect this "edge case".
So I guess (in theory) the normalizer could have handled that missing range
> as an irrelevant revision for eliding the remaining branches. Wouldn't it
> be possible/useful to handle that by the tool automatically?
>
My speculation is that r190854 also touched node properties or
so and SVN then decided to not include that creation into the
sub-tree mergeinfo. Could also be / have been a quirk in the
client code.
> Regarding your other questions I'll get back to you later.
>
Thank you very much!
-- Stefan^2.
Re: inconsistency between mergeinfo records
Posted by Stefan Hett <st...@egosoft.com>.
Hi Stefan^2,
> 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.
[...]
I gave the normalizer a first run and using it I was able to reduce our
record of mergeinfos quite significantly without too much manual work.
So alltogether I'd consider this a really useful tool.
I sent you the logs per PM so you can take a look at all the details
yourself (some of the information contained in the logs I do not want to
make publicly available on the mailing list and it's quite some large
logs (several MB)).
Note that running normalize at the beginning, could not remove any
redundant mergeinfos at all, since there were always some revisions
missing. However running the following sequence of commands first:
1. clear-obsoletes
2. combine-ranges
3. normalize
Then was able to remove a significant amount of redundant mergeinfos
(eliminating mergeinfos on over 100 files).
There were still some remaining records. These I managed to get rid of
by manually merging the missing ranges.
One remaining case which couldn't be normalized automatically was on
"/src/version_generator".
Revision 190854 was recorded on root and on src but not on
src/version_generator.
190854 was actually the creation of a branch (XRebirth/branches/XR_ogl).
So I guess (in theory) the normalizer could have handled that missing
range as an irrelevant revision for eliding the remaining branches.
Wouldn't it be possible/useful to handle that by the tool automatically?
Regarding your other questions I'll get back to you later.
Regards,
Stefan
Re: inconsistency between mergeinfo records
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Feb 24, 2015 at 6:27 PM, Bert Huijben <be...@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]
> *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 <st...@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
> >
>
>
>