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

Re: detection of moved branches for svn-normalizer tool

From: Stefan Hett <stefan_at_egosoft.com>
Date: Tue, 25 Aug 2015 14:41:07 +0200

> On Wed, Jul 22, 2015 at 12:07 PM, Stefan Hett <stefan_at_egosoft.com
> <mailto:stefan_at_egosoft.com>> wrote:
> Hi,
> 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?
> The latest tool version distinguishes between 3 different cases of
> "missing" branches:
> * "potential branch" - the (sub-)path never existed. That tends to
> happens for old branches
> which have not been sync'ed with /trunk for a long time.
> * "surviving copies" - path got deleted but there are still copies of
> it (or copies of copies).
> Even if only parts got copied, they still count.
> * "deleted with no surviving copies"
> Only the last kind will be removed automatically. In the other cases,
> it is up to the
> user to decide whether to keep the mergeinfo or not.
> 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:
> /SDK/FooSDK/trunk:2-3
> /SDK/FooSDK2/tags/v2:6
> /SDK/FooSDK2/trunk:4
> 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.
> That's how it is implemented now.
> -- Stefan^2.
So if I get you right, running "svn-mergeinfo-normalizer normalize
--remove-obsoletes" should not remove FooSDK.
If so, I think I ran into a bug here. Tested on our productive
environment (rather than on this test-case) and it removed the entry in
this case for SDKs\CrashServer\trunk.

Following is the relevant output from the analyse -v run:
Trying to elide mergeinfo from path
     into mergeinfo at path
     Removing obsolete entries ...
     has SURVIVING COPIES: /SDKs/CrashServer/trunk
         e.g.: /SDKs/DrDump/trunk
Encountered 1 missing branches:
     [r185624, copied or moved] /SDKs/CrashServer
         -> /SDKs/DrDump

So to me the analyse output sounds correct. It detected that
/SDKs/CrashServer/trunk no longer exists on head but was renamed to
/SDKs/DrDump/trunk and therefore flagged as having surviving copies.
Still the normalize run seems to remove the entry.

Am I getting something wrong her?

Stefan Hett
Received on 2015-08-25 14:41:31 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.