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
