On Mon, Jan 01, 2001 at 08:57:14PM -0600, Karl Fogel wrote:
> 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.
We also have a notion of an immutable revision of a file. A new revision is
created during each commit. We do not update other files (since they do not
participate in the commit).
DeltaV has an analogous concept called a "version resource." URLs are used
to find these resources. The ideal situation is to have a 1-to-1 mapping
between URLs and the resources (technically, you could have multiple URLs
identify a given resource, but that poses problems with the DAV:version
> 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?
Correct. A "cookie" is a great way to describe the version resource URL (and
a few other URLs the server returns).
> 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?).
So far, it does appear that way. The mapping is not ideal, however, and the
"creation" of URLs for resources which haven't really change could pose
interop issues in the future.
> I just hope nothing more
> serious bites us in the future...
I'm hoping to avoid that, thus my suggestion.
> 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.
Depends: we can also update the URL to track the changing revision number.
But that has the size issue that I've mentioned. Letting it fall "out of
date" appears to be okay.
> 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.
This part of "we" doesn't agree it is a problem. The FS exposes a concept of
unique nodes. These are identified with a thing called an "ID". If the
identification mechanism ever changes (e.g. the IDs are no longer
persistent), then we simply update how the version resource URL is
constructed. Let's say the ID concept is removed; fine, we switch to
rev/path (or whatever the heck is introduced in its place).
But the true point is that it doesn't matter what is in that URL, as long as
the client treats it opaquely. We have different optimizations and tradeoffs
that can be made based on its construction, but the system still works.
The question is still based on the original subject "(FS) operational
question" -- can we introduce an extra API so that we can access a node more
directly? Right now, we have: (rev, path) -> ID -> node. The modelling will
be much more ideal if we can use the ID.
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:19 2006