[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

detection of moved branches for svn-normalizer tool

From: Stefan Hett <stefan_at_egosoft.com>
Date: Wed, 22 Jul 2015 13:07:43 +0200


I came across a case where svn-normalizer did remove mergeinfo for a
branch which was still present but got renamed in one revision.
I understand why it behaves the current way, but maybe in favor of the
improvements done for handling moves it might also be a good idea to
have svn-normalizer better handle these scenarios?

For a quick demo/test-case showing the underlying issue, I've attached a
batch-file (for windows) demonstrating the case.

As you see the resulting mergeinfo for FooProject/FooSDK is:

Running svn-normalizer analyse now reports
/SDK/FooSDK as a deleted branch (in r4) and running svn-normalizer
normalize --remove-obsoletes would then drop this mergeinfo.

Suggested behavior would be that if a branch is renamed and still
present on trunk, it would not be removed when using svn-normalizer
normalize --remove-obsoletes.


Received on 2015-07-22 13:08:39 CEST

This is an archived mail posted to the Subversion Dev mailing list.