[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS: Plan of attack

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-04-11 17:58:17 CEST

On Sat, 2004-04-10 at 20:59, Edmund Horner wrote:
> Greg Hudson wrote:
> | (1) At the API level
> | (2) At a level which lets libsvn_fs_fs reuse the DAG logic (tree.c)
> | (3) At the level appropriate for pluggable DB support

> By now I realise (only slightly self-pityingly) that I'm not going to
> influence any of you one way or the other, but:

What does this mean? It seems like as the author of a prototype SQL
implementation, you'd have a unique view on where (3) should lie.

> 1. Doesn't the existence/level of a lower-level abstration depend on the
> implementation of a higher-level abstraction?

Sorry, that was supposed to be implicit. If we have abstraction layer
(1), then layer (2) only applies to the implementations which follow the
current implementation fork, and likewise if we have distinct
abstractions at both (2) and (3) (as CMike wishes to avoid), only
implementations which follow the current implementation fork at (2)
would be participating in the abstraction at (3).

Glenn Thompson wrote:
> I'll finish the HTML formatting as soon as possible so folks can
> modify the document if they wish.

This document has the same problem as your "master patch": it's 31 pages
long and hard to digest. We really, really need your contributions to
this process to be concise, focused, and objective. If we're arguing
about a particular aspect of FS abstraction and you have an opinion
about it, we need you to give your opinion about just that one question,
not say, "I've been working on this big document with diagrams over here
and part of it talks about that; please go read it."

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 11 17:59:43 2004

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.