> 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.
[...]
> However, it turns out (A) is okay, albeit still not ideal, because
> that out-of-dateness isn't actually going to hurt anything.
It might affect interoperability with other DeltaV clients in the long
term. Although Subversion thinks in terms of "one revision for the
entire tree, with allowed variances in the working copy and lost of
optimizations to minimize the cost of going between revisions," DeltaV
thinks in terms of independently versioned resources--more like RCS.
Correct me if I'm wrong, Greg. (As one of the Gregs, I get to say
"Greg" without being ambiguous.)
So, in Subversion, when we change file A but not file B, it's natural
to assume that the canonical most recent revision of file B has
increased. But in DeltaV, that is not natural.
> 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.
The client isn't really using that information; it doesn't get to
actually "know" the node revision number. It's just acting as an
information store for the server. Although we do open ourselves up to
the possibility of poorly written clients which irresponsibly dissect
the supposedly-opaque version resource URL.
> You are fluent in both, but most Subversion developers are only
> fluent in the first (with the exception of Greg Hudson, maybe).
I'm not really fluent, just cocky. :)
Received on Sat Oct 21 14:36:19 2006