Hi Alfred,
On 6/2/2017 2:48 PM, Mark Phippard wrote:
Actually, this is the newer tool I was thinking of:
http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer/
On Fri, Jun 2, 2017 at 8:46 AM, Mark Phippard <markp...@gmail.com
<mailto:markp...@gmail.com>> wrote:
Have you seen this script?
http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/mergeinfo-sanitizer.py
<http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/mergeinfo-sanitizer.py>
I believe it does this though I have never tried it.
On Wed, May 31, 2017 at 11:18 AM, Alfred von Campe
<alf...@von-campe.com <mailto:alf...@von-campe.com>> wrote:
After many years of development, we have over 100 entries in
the svn:mergeinfo property of our trunk. I am thinking about
manually editing the property to remove entries for all
branches that have been deleted or are no longer used (and
should be deleted). I am hoping that once I merge trunk into
the other active branches, the cleanup of that property will
also propagate to the other branches.
So my questions are:
* Is this safe to do?
* Will the changes to the properly be merged to all other
branches over time as one would expect?
jcorvel made me aware of your post here.
I'm regularly using the svn mergeinfo normalizer myself. It should suit
your requirements quite well, but you'd be aware that it hasn't been
tested thoroughly by a lot of people, since it's a new tool in the not
yet released 1.10 development branch.
To get some basic documentation about what the tool does, best start
with the integrated help (svn-mergeinfo-normalizer help).
In your case all you might actually need is to run
"svn-mergeinfo-normalizer normalize --remove-obsoletes" followed by
committing the changes. Carefully verify the changes before committing
them. As said: The tool hasn't gotten much test coverage by a broader
audience yet.
There are also other useful commands (--remove-redundant which tries to
elide unnecessary mergeinfo entries as well as --combine-ranges which
will combine mergeinfo ranges into shorter representations where possible).
Useful is also its "svn-mergeinfo-normalizer analyze" command, which
will print out the information about why certain mergeinfos could not be
elided (possibly providing you with the necessary information to correct
some invalid/incorrect mergeinfo entries which might have built up over
time).
As said above: I cannot emphasize enough to be careful with using that
tool atm. While I've personally been playing around with it for over two
years now, it might still contain undetected issues/bugs.
If you wanna give it a quick try and are running on Windows, there are
prebuilt binaries available for MaxSVN (disclaimer: that's a development
binary distribution of SVN I'm maintaining):
http://www.luke1410.de/typo3/index.php?id=97. Download MaxSVN
trunk-dev-r1771118-1 and run svn-mergeinfo-normalizer contained in the
package. I'm not aware of other prebuilt sources of the current SVN
development branch (otherwise I'd have listed them here as other examples).
On a more general note on your questions:
Is it safe to do that (i.e. remove the entries for obsolete/removed
branches)?
Kind of. If your working process means that you are not going to
reinstate the removed branch in a future revision again to merge
remaining revision from it to some other branch, I'd personally consider
it a safe habit to drop the then obsolete mergeinfos. If your work
process differs, you should not remove it though IMO, since then you
might cause conflicts on merges and also lose the information about what
was merged of the other branch (if it later is reinstated).
Will the changes to the properly be merged to all other branches over
time as one would expect?
That depends on how your merge process goes and how previous merges were
done. Simply speaking, I'd suggest to remove the obsolete mergeinfos
from any branch (not only trunk or specific development branches). Not
doing so can reinstate the removed obsolete mergeinfos again (due to
following merge operations). Another situation you would prevent by
completely removing obsolete branches from the entire repository are
mergeconflicts which can occur if you merge the revision where the
obsolete branch was removed from into another branch.
--
Regards,
Stefan Hett
