Re: issue with relative externals after a rename

On Tue, Mar 27, 2018 at 11:36 PM, Branko Čibej <brane_at_apache.org> wrote:

> Because the default operative revision is HEAD and there's no such
> object in HEAD, yes.

[snip]

> You need both peg and operative revisions:
>
> -r 18 ../fold1 fold1_at_18
> -r 18 ../fold2/file1.txt_at_18 file1.txt
>
> The peg revision tells Subversion which object to look for and the
> operative revision tells it which version of that object to use.
>

 And then...

On Wed, Mar 28, 2018 at 3:12 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:

> Are you sure? That's surprising to me, because for normal commands the
> operative revision always defaults to the peg revision.
>
> For example, in [1] I read "Notice that we didn't provide an operative
> revision this time. That's because when no operative revision is
> specified, Subversion assumes a default operative revision that's the
> same as the peg revision."
>
> Or is there a different rule for externals definitions?
>
> [1] http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
>

Oops, that makes me a bit nervous about how we've set up our
externals.

Our requirements are: at any time in the future, if someone checks
out code from the past, they should get exactly the same tree as what
existed in the past. I assume that this is probably THE #1 use case
and desired behavior for externals. Is that correct? If not, is there
a good reason to want otherwise?

My understanding is that:

(1) ^/SVN/path/to/project/tags/specific_tag

    That will probably work most of the time but if someone commits
    to that tag, future checkouts of past revisions will not look
    exactly as they did in the past.

(2) -r [number] ^/SVN/path/to/project/tags/specific_tag

    Subversion first goes to that path, then follows it back in time
    to the specified revision.

    So if someone commits to that tag, the future checkout of the
    past revision will get the past revision.

    But... if a tag is ever moved, removed, or renamed in the future,
    (the project is declared defunct and removed, for example), what
    Subversion finds at that path and tries to follow back in time
    won't lead to the right place.

(3) ^/SVN/path/to/project/tags/specific_tag@[number]

    Subversion first goes back in time to that revision, then goes to
    that path.

    This is where I'm a bit foggy: Once it goes back in time and goes
    to that path, does it then follow it forward to HEAD? Or does it
    stay in the past?

We've set up all of our externals like (3)... Do we need to go
through our repo and change all externals to specify both the peg
and operative revision?

Thanks,
Nathan Hartman
Received on 2018-03-28 16:36:59 CEST