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

FS abstraction and node-rev IDs

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-04-30 05:10:19 CEST

I probably should have brought this up earlier, but there's still
plenty of time to change the solution before a release.

The node-rev-ID structure and the functions svn_fs_parse_id,
svn_fs_unparse_id, svn_fs_check_related, and svn_fs_compare_ids are
currently implemented directly by the loader library; they don't go
through vtables. The fundamental reason is that svn_fs_unparse_id()
does not take an FS object, so there's no good way to determine which
vtable to use.

Josh and I were able to shoehorn FSFS IDs into the
node-id.copy-id.txn-id structure, but that doesn't make the situation
any more elegant. Here are some alternatives:

  * Deprecate svn_fs_unparse_id(), make an svn_fs_unparse_id2() which
    accepts an FS object, and make it so code using
    svn_fs_unparse_id() only works with BDB FS IDs.

  * Stick an FS-type identifier on node-rev IDs which don't belong to
    BDB filesystems, and use that identifier to look up the vtable
    name. This seems like a potential source of security problems if
    any code accepts node-rev IDs from an untrusted source; we'd have
    to be careful in every FS function which uses node-rev IDs to
    ensure that we weren't fooled into parsing the ID into the wrong
    kind of structure.

There may be other options as well. When svn 2.0 rolls around, we can
of course change svn_fs_unparse_id() to take an FS object by fiat, and
not worry about old code.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 30 05:10:37 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.