[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-dev
Subject: Re: detection of moved branches for svn-normalizer tool
From: Stefan Hett <stefan () egosoft ! com>
Date: 2015-08-25 12:41:07
Message-ID: 55DC6263.6070005 () egosoft ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
</div>
<blockquote
cite="mid:CA+t0gk090OyoZppkXTATQL3eGezCFUR6ZApjOAxZ53Yv1GhnOg@mail.gmail.com"
type="cite">
<div dir="ltr">On Wed, Jul 22, 2015 at 12:07 PM, Stefan Hett <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:stefan@egosoft.com" target="_blank">stefan@egosoft.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I came across a case where svn-normalizer did remove
mergeinfo for a branch which was still present but got
renamed in one revision.<br>
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?<br>
</blockquote>
<div><br>
</div>
<div>The latest tool version distinguishes between 3
different cases of "missing" branches:<br>
<br>
</div>
<div>* "potential branch" - the (sub-)path never existed.
That tends to happens for old branches<br>
</div>
<div> which have not been sync'ed with /trunk for a long
time.<br>
</div>
<div>* "surviving copies" - path got deleted but there are
still copies of it (or copies of copies).<br>
</div>
<div> Even if only parts got copied, they still count.<br>
</div>
<div>* "deleted with no surviving copies"<br>
<br>
</div>
<div>Only the last kind will be removed automatically. In
the other cases, it is up to the<br>
</div>
<div>user to decide whether to keep the mergeinfo or not.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
For a quick demo/test-case showing the underlying issue,
I've attached a batch-file (for windows) demonstrating the
case.<br>
<br>
As you see the resulting mergeinfo for FooProject/FooSDK
is:<br>
/SDK/FooSDK/trunk:2-3<br>
/SDK/FooSDK2/tags/v2:6<br>
/SDK/FooSDK2/trunk:4<br>
<br>
Running svn-normalizer analyse now reports<br>
/SDK/FooSDK as a deleted branch (in r4) and running
svn-normalizer normalize --remove-obsoletes would then
drop this mergeinfo.<br>
<br>
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.<br>
</blockquote>
<br>
</div>
<div class="gmail_quote">That's how it is implemented now.<br>
<br>
</div>
<div class="gmail_quote">-- Stefan^2.<br>
</div>
</div>
</div>
</blockquote>
So if I get you right, running "svn-mergeinfo-normalizer normalize
--remove-obsoletes" should not remove FooSDK.<br>
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.<br>
<br>
Following is the relevant output from the analyse -v run:<br>
[...]<br>
Trying to elide mergeinfo from path<br>
C:/[...]/src/SDKs/DrDump<br>
into mergeinfo at path<br>
C:/[...]/src<br>
[...]<br>
Removing obsolete entries ...<br>
has SURVIVING COPIES: /SDKs/CrashServer/trunk<br>
e.g.: /SDKs/DrDump/trunk<br>
[...]<br>
Encountered 1 missing branches:<br>
[r185624, copied or moved] /SDKs/CrashServer<br>
-> /SDKs/DrDump<br>
[...]<br>
<br>
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.<br>
Still the normalize run seems to remove the entry.<br>
<br>
Am I getting something wrong her?<br>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Stefan Hett</pre>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic