Greg Stein <gstein@lyra.org> writes:
> Sigh...
>
> THAT is why I want to remove the revision number from the URL!
Sorry if I'm being dense.
A big part of the problem here is that two different languages are
being spoken: Subversion and DAV/DeltaV. You are fluent in both, but
most Subversion developers are only fluent in the first (with the
exception of Greg Hudson, maybe). Your quick summary of what a
version resource is helped a lot, though, thanks.
What's really happening is that we're running into the long-feared
Subversion/DAV mismatch. Let's face it, given Subversion's primitives
-- revisions and paths -- one wouldn't normally come up with a network
protocol that looks anything like the one we're using. So far, you
have heroically borne the entire burden, carefully bending DAV to work
with what Subversion offers it (I'm not being sarcastic at all here,
by the way, don't know if that's apparent by email).
Now we have the first instance where a part of the DAV world really
threatened to impinge on Subversion. I had thought that whatever DAV
needed it could *construct* based on the visible working copy
metadata, but I was wrong: some of the DAV data is deliberately
opaque, essentially just a cookie the server hands to you to identify
which resource you have. The cookie contains information, but not
information anyone but the server is technically allowed to decode.
Thus, the cookie cannot be updated by the client, and will get
out-of-date if the client bumps local revision numbers even on
entities that were not mentioned explicitly in the network traffic.
Is this a fair summary of the situation?
BUT: we're saved this time by the fact that this out-of-dateness turns
out not to hurt anything (is that a correct understanding of the
conversation you and Greg H just had?). I just hope nothing more
serious bites us in the future...
So, the problems were:
A. If we store a revision number in the opaque Version Resource
URL, then it can become out of date with the revision as stored
in the entries file.
B. But if we store a hard node revision instead... Well, maybe we
can't think of a bad effect up front, but I'm sure we all agree
there's something deeply icky about storing that stuff anywhere
on the client side. It's internal to the fs and the fs's
immediate callers. Using it on the client side seems guaranteed
to lead to badness down the road.
However, it turns out (A) is okay, albeit still not ideal, because
that out-of-dateness isn't actually going to hurt anything.
Is this the planet you were looking for?
-K
Received on Sat Oct 21 14:36:19 2006