Greg,
The doc string for svn_wc_entries() reads thusly:
/** Parse the `entries' file for @a adm_access and return a hash @a
entries,
* whose keys are (<tt>const char *</tt>) entry names and values are
* (<tt>svn_wc_entry_t *</tt>). The hash @a entries, and its keys and
* values, are allocated from the pool used to open the @a adm_access
* baton (that's how the entries caching works). @a pool is used for
* transient allocations.
...
We've discussed before that removing the entries cache in adm_access
will lead to memory explosion, as the entries are re-read from disk
into the access pool, without ever freeing memory used for stale
entries hashes. (Well, it will lead to *faster* memory explosion,
since we still flush the cache under certain circumstances.)
However, as we start touching the sqlite db directly, the cache
becomes stale quite quickly, since the entries hash isn't modified at
the same time the the db is, has happens with
svn_wc__entries_modify(). Since we're not using adm_access anymore,
we've no way of knowing when to flush the cache, which means we'll
need to flush it aggressively--so aggressively that it probably isn't
worth keeping the cache around.
As for API consumers which are using entries and now have sub-optimal
memory consumption, I say "tough rocks, upgrade to the new APIs".
That might be harsh, but I think it's the reality as keeping the cache
in sync is much more trouble than it's worth.
Thoughts?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377195
Received on 2009-07-31 04:49:02 CEST