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

Re: [PATCH] Use serialized hashes for node-origins records in FSFS [unfinished]

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 1 Feb 2008 11:48:30 -0800

On Feb 1, 2008 11:08 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> I think Glasser's approach of using node revisions IDs to store origins is a
> very good one, and would encourage him to go ahead with that approach. I'd
> still be happiest if he consider a hybrid model -- I don't think the
> "switching code" that would have to bridge the two approaches would really
> be that hard to deal with. svn_fs_fs__set_node_origin() use the current
> approach; at commit time the logic would use the old approach;
> svn_fs_fs__get_node_origin() would check the node_id for an origin, and
> failing that check the disk for a record. Seems purty straightforward.

OK, I think the hybrid approach is reasonable enough. We can use the
cache for node-ids only for node-IDs that don't have a '-' in them.
Folks willing to dump/load (and new repositories) would never need to
do any IO here. Those not willing will have increased disk space
usage (and a small amount of IO). It's more code complexity than I'd
like, and I still haven't seen anyone come forward and put themselves
firmly in the spot of "I'm an FSFS user who's unwilling to dump and
load and whose repository is large enough that the uncached walk is
too slow", but I'd rather we make some progress than debate
hypotheticals for another. I'll review your patch and merge it with
mine and commit.


David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-01 20:48:44 CET

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.