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?
