On Tue, Mar 27, 2018 at 11:36 PM, Branko Čibej <br...@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@18 > -r 18 ../fold2/file1.txt@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 <jcor...@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