Hi,
On Wed, Jul 22, 2015 at 12:07 PM, Stefan Hett <ste...@egosoft.com
<mailto:ste...@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
