Re: http://subversion.tigris.org/issues/show_bug.cgi?id=2516
"--revision option is not forwarded to svn:externals references"
Mark Phippard wrote:
> Julian Foad wrote:
>> No, the issue is about when head is r5678 and I request "svn update
>> -r100" then I want the externals to be updated to r100 not to r5678.
>
> OK, I was extrapolating a bit. Is svn up (implicit HEAD) any different? If
> HEAD is r5678 when it updates the main WC and r5680 when it gets to the
> external ... to me that is the same problem.
Hi Mark.
This is an interesting tangent.
You're talking about the problem of what I'll call 'skew' that results
if we look up the revision number corresponding to 'head' more than
once in any given repository: the look-ups can give different results,
whereas we would benefit from more consistent results if we use the
same value throughout the whole execution of the recursive update.
If 'svn up' (implicit HEAD) finds head is 5678 and then it updates an
external in the *same* repository to 'head', and looks up head again
and finds r5680, then that is a 'skew' problem.
We can and should eliminate in-repository skew by performing exactly
one 'head' look-up per repository, within any one command. (Long-lived
clients may determine the appropriate scope in some other way than
"one command".)
A similar issue that I'll lump under the general term 'skew' exists
between different repositories.
If 'svn up' (implicit HEAD) finds head is 5678 and then it updates an
external in a *different* repository to 'head', then it has to perform
a look-up of head in the different repository. It is not possible to
perform the two look-ups synchronously (unless the repositories are
both managed by some external system that makes this possible). In
general there is no correlation between the commits in each
repository, so the result of looking up 'head' in the second
repository may be 123 or 1000009 or anything, and also, independently,
it may have been committed a long time earlier or later than our r5678
was.
We could take steps to reduce cross-repository skew. For example, we
could start by determining the set of repositories to be contacted,
and trying to do 'head' look-ups in these repositories all at the same
time as closely as possible. We cannot do this completely, because
until we have performed the first level of checkouts/updates we will
not know what further repositories will be contacted by nested
external definitions.
Skew is also potentially a problem for date look-ups. I can think of
at least three cases:
* I commited a revision rA to REPO_A and a revision rB to REPO_B
"at the same time". Updating an external defined in REPO_A at rA, it
points to REPO_B, so I look up the date of rA => DATE_A and then I
look up DATE_A in REPO_B. The inevitable clock skew between different
repository servers means that the result of looking up DATE_A in
REPO_B will unpredictably give a result that is somewhere around rB
but just as likely to be (rB - 1) if there is any clock skew at all,
and may be a few revisions either side of rB.
* We look up a date that is approximately 'now' but is in fact
slightly later than that repository's clock, and the that repo gets
another commit, and then we look up that same date and it returns the
new commit.
* We look up the same date twice in the same repository and the
result changes because someone modified an svn:date revision property.
The 'skew' problem may exist for any command that makes multiple
accesses to the same or different repositories -- externals are not
needed. It is related to, but different from, almost orthogonal to the
issue at hand: either issue could exist or not without materially
affecting the other.
> As I said, I think if someone really thought the current behavior was what
> they wanted then couldn't they add an explicit -r HEAD to the external
> definition?
>
> This still seems like something we could treat as a bug.
C-Mike already answered that in
subversion.tigris.org/issues/show_bug.cgi?id=2516#desc2 : "That's not
a workaround, because folks can't go back and change old svn:externals
definitions to have that -rHEAD [...]"
- Julian
Received on 2015-08-27 12:13:02 CEST