[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: Edmund Horner <chrysophylax_at_chrysophylax.cjb.net>
Date: 2004-04-11 02:59:02 CEST

Hash: SHA1

Greg Hudson wrote:
| So, if I understand all this right, there are three possibly distinct
| places to chop up libsvn_fs:
| (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
| As I understand it, you are in favor of chopping at (1) now, (3) when
| someone actually gets around to writing an SQL back end, and (2) never,
| presumably because chopping up the current FS implementation in two
| places would make it hard to maintain.
| My question is: how far apart are (2) and (3)? I think I have seen some
| argument over how much of the schema should be assumed by the
| pluggable-DB abstraction layer.

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

1. Doesn't the existence/level of a lower-level abstration depend on the
implementation of a higher-level abstraction? E.g. there might be two
implementations at level (1):

~ - libsvn_fs_fs, where the higher-level FS stuff is closely tied to the
storage, so there's no need/room for further abstraction.
~ - libsvn_fs_default (the existing file system), with abstraction (2)
below it.

At level (2) in svn_fs_fs there might be two implementations:

~ - libsvn_fs_bdb (existing BDB storage).
~ - libsvn_fs_sql (SQL storage), with abstraction (3) to allow for a
growing range of SQL client libraries/dialects.

Obviously a nice tree diagram can be imagined here, with the salient
feature that *not all leaves are the same distance from root*.

Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 11 02:59:27 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.