subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Kadel-Garcia <>
Subject Re: issue with relative externals after a rename
Date Wed, 28 Mar 2018 14:59:28 GMT
On Wed, Mar 28, 2018 at 10:36 AM, Nathan Hartman
<> wrote:

> 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?

Then make tags. Tags need to be locked down, with no commits permitted
on top of the tag.

> 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.

See above. "No commits permitted on top of the tag".

> (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

If you're permitting commits on top of tags, probably so.

View raw message