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
Received on 2015-07-20 20:26:55 CEST