[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 15:07:25 CET

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

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