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

Re: reasonable to keep a hash of all new node IDs in memory during a commit?

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-11-17 09:10:48 CET

David Glasser wrote:
> On Nov 16, 2007 6:47 PM, David Glasser <glasser@davidglasser.net> wrote:
>> The node-origin-in-sqlite code is now on trunk and used by FSFS. The
>> cache is only populated on a miss; it should be straightforward to
>> also populate it after a commit. (Specifically, during
>> svn_fs_fs__commit *after* the write lock is released.)

You are a rock star. And my current fave at that.

>> Just one question: is it OK to build up a hash in memory mapping new
>> node IDs to noderev IDs, or does that violate the "don't keep
>> arbitrarily large things in memory" rule? I think it should be OK
>> because every new node ID has a changed-path entry, so the size of
>> this hash would be no bigger than the size of a revision's
>> changed-paths hash, and we keep those around in memory all the time.

No bigger than? This will arguably be much smaller than the corresponding
changed_paths hash. In the spirit of consistent less-than-idealism, +1 to
commit. :-)

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Sat Nov 17 09:11:00 2007

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.