[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:28:52 CET

Greg Stein <gstein@lyra.org> writes:
> > 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.

Okay, gotcha.

> 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.

Yah. Jim will be back on the 3rd, he's best qualified to answer that.

-K
Received on Sat Oct 21 14:36:19 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.