Re: detection of moved branches for svn-normalizer tool

Hi,
> 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
     C:/[...]/src/SDKs/DrDump
     into mergeinfo at path
     C:/[...]/src
[...]
     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?

-- 
Regards,
Stefan Hett