You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/11/17 02:47:46 UTC
reasonable to keep a hash of all new node IDs in memory during a commit?
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.)
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.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reasonable to keep a hash of all new node IDs in memory during
a commit?
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Nov 16, 2007 6:47 PM, David Glasser <gl...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: reasonable to keep a hash of all new node IDs in memory during a commit?
Posted by David Glasser <gl...@davidglasser.net>.
On Nov 16, 2007 6:47 PM, David Glasser <gl...@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.)
>
> 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.
I committed this in r27893, but would still appreciate the sanity check.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org