Ping!... Stefan H or Stefan F, is there anything further to report on
this issue?
- Julian
On 25 August 2015, Stefan Hett wrote:
> On 17 August 2015, Stefan Fuhrmann wrote:
>> On Wed, Jul 22, 2015, Stefan Hett wrote:
>>> 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?
Received on 2016-01-05 15:56:57 CET