On Mon, 2004-05-10 at 06:01, Greg Stein wrote:
> "could be" is very different from "probably". I'm with Branko here: I
> don't think any of the other forseeable backends would use skels. Thus,
> I'd say to leave them with the BDB implementation unless/until another
> backend needs them. At that point, they can migrate.
Agreed.
> btw, I don't like the library explosion (it becomes very slow to load and
> link all those libs -- just ask the GNOME folks), but libsvn_fs_subr does
> seem to be the cleanest approach at the moment.
For the record, when I did the work, I determined that FSFS really wants
a different ID implementation from BDB. (It's possible to use the same
implementation for both and layer some goo on top in the FSFS layer, but
it's inelegant, and there's just not enough code reuse potential to
justify a sacrifice of elegance.) So, that leaves, for libsvn_fs_subr:
* The key-gen functions
* svn_fs__canonicalize_path
Although I won't object if someone else wants to create a
libsvn_fs_subr, I couldn't justify it to myself for such a small amount
of code. Since only svn_fs__canonicalize_path had been abstracted out
before, I just duplicated it in the two FS modules.
Incidentally, both of those pieces of functionality seem like reasonable
fodder for libsvn_subr (unlike node-IDs), although we'd need to look
carefully for FS-specific assumptions in their contracts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 16:56:08 2004