Re: [vote] pin-externals branch to trunk
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 3 Feb 2015 15:17:05 +0000
Stefan Sperling wrote:
Oh yes, makes sense. (My thinko. I was mistakenly thinking that the default revision for an external was whatever the revision of the directory carrying the svn:external property, but it's not; and that could only make sense within the same repository.)
> If the copy source is a WC, we pin externals to the revision they were
(Not an error if an already-pinned external is not checked out, I hope.)
A checkout of a tree is, in general, mixed revision. I can see how using the WC revision feels right if it's a single-revision checkout: a future checkout will recreate exactly what was in the WC. But if it's mixed-rev, what do you do then, and why? I guess you take the root node's base revision and ignore the rest. A future checkout won't then recreate what was in the WC.
If the behavioural intent is to make a copy that looks like the WC, then in cases where that's not easily achievable, I think silently picking one revision is not a very robust behaviour. I think it would be preferable to error out or something.
Also if the external checked out in the WC is locally modified, then pointing to its base rev does not have the effect of preserving a snapshot of what was in the WC. Perhaps best to error out (or something) in this case too. And probably if it contains switched, sparse, etc. content too.
>> Perhaps now adjust svncopy.pl's help text to mention that its '--pin-externals'
I suggest leaving it there so that people already using it have a chance to change over gradually and to see any additional message that you insert in it.
>>> Externals are "pinned" by adding a peg revision to the external's
Ahh, so the question "is it pinned?" translates only to "is a peg revision specified?". I understand why: because if there's no peg then the URL (with implicit peg rev 'head') is not a stable reference.
(Note: In the old syntax, a revision specified as "-rX" acts as both a peg revision and an operative revision.)
> Pinning won't work with exernals which have been deleted in HEAD at
Yes of course -- this should work analogously to 'update' and every other command that looks at externals. If they error out, or give a warning, or silently skip when an external target cannot be accessed, then this should behave in a similar way.
> Adding a peg revision to pinned externals has the advantage that tags
Yes -- totally necessary if the intent is to produce a stable tag.
> Any -rN present in the externals definition is left as-is, since by
I get it now, and agree.
> Also, the kind of revision specification is left as-is,
I get the part about adding a peg rev and keeping the time stamp operative rev.
(Looks like timestamp revs have an issue with ambiguous time zone. That's a separate problem, but I wonder if converting it to a Zulu time at this point is the right thing to do.)
>> When we change the definition to make it pinned, we add a peg
No: according to The Book, the old "-r" is a peg-and-operative rev, so 'PATH -rX URL' is exactly equivalent to 'URL_at_X PATH'.
> And unfortunately the parsed external representation doesn't convey which
As is being discussed on IRC, if we need to do this, then we could convey that extra information through private APIs.
This is an archived mail posted to the Subversion Dev mailing list.