-----BEGIN PGP SIGNED MESSAGE-----
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*.
Edmund.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAeJhWEbvImmpUq7gRAgsKAJ9m9WJuYYTKA4VI2XYtFNOvy+hFmgCgjpkk
l/ZqFKHmoSHZqkj0hTZGBLk=
=91ii
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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