subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hett <ste...@egosoft.com>
Subject Re: detection of moved branches for svn-normalizer tool
Date Tue, 25 Aug 2015 12:41:07 GMT
Hi,
> On Wed, Jul 22, 2015 at 12:07 PM, Stefan Hett <stefan@egosoft.com 
> <mailto:stefan@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


Mime
View raw message