Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
Just a nit, more for people who aren't following this as intensely as
you are:
It's never an assumption, rather always a known thing. We update the
revision number on file B only when B is updated -- it just happens
that sometimes you update a file and receive the "empty change". :-)
(That's what you meant, I think, I just wanted to head off any
misunderstandings at the pass.)
> > 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.
True, it's used only by the networking layer, not by purely
client-side code. But still, icko, ya know?
> > 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. :)
"Laziness, impatience, and hubris." Hey, you've got at least one out
of three, then... :-)
-K
Received on Sat Oct 21 14:36:19 2006