On Wed, Jul 22, 2015 at 12:07 PM, Stefan Hett <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.
Received on 2015-08-17 02:12:12 CEST