[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: (FS) operational question

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2001-01-02 03:57:14 CET

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?

Received on Sat Oct 21 14:36:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.