On Tue, Jan 02, 2001 at 12:34:48AM -0500, Greg Hudson wrote:
> > 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.)
You're right... Greg :-).
Actually, Subversion's concept of "one revision for the entire tree" has a
correspondence in DeltaV: they're called "baselines". DeltaV clients that
understand baselines will be able to work very well against an SVN server.
Baseline "7" maps directly to revision 7 of our tree.
[ there is a way to fetch a baseline by name; we'll assign revision numbers
as names; if we tag/label a revision, that will actually be another name
for a baseline; note that when a client ask for -r7, we'll consult the
baseline to get it. ]
[ it is interesting to note that (it appears) nothing in the DAV code
(client or server) really cares about revision numbers or their sequential
nature. The revisions could be "alpha" and "beta" for all it cares.
post-V1, I want to look into this some more to see just how independent we
are; if we can manage to make the (entire) client independent, then it
could work against any DeltaV server that does baselines. ]
> 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.
Well-stated.
Geoff Clemm has expressed a concern that the "creation" of the extra version
for file B could create an interop problem. I'm not entirely sure that I
agree, but Greg's "natural-ness" is a good way to describe my unease with
the rev of file B.
Another point about why 1-to-1 mapping of URL to resource is handy: caching
proxies. Even though v67 and v73 might be the same, the proxy will still
need to fetch it.
> > 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.
Agreed.
> Although we do open ourselves up to
> the possibility of poorly written clients which irresponsibly dissect
> the supposedly-opaque version resource URL.
We'll cover our butts quite a bit because other clients will want to use
libsvn_client (or even libsvn_ra_dav). But your point is still valid.
Even so... I happen to have no sympathy for those guys :-) F'em. :-)
> > 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. :)
hehe... Well, you're doing quite well from where I'm sitting. And if you get
out of line, then I'll just smack ya down :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:19 2006