Ben Collins-Sussman <sussman@collab.net> writes:
> Philip Martin <philip@codematters.co.uk> writes:
>
>> Yes, that's correct. Any operation that opens the whole tree reads
>> all the entries files at the start. I suppose read operations could
>> be made more streamy (although it may well not be a trivial change),
>> but would we want to do that for write operations? At present if part
>> of a wc needs 'svn cleanup' an update/commit operation fails before
>> doing any network stuff, in the past it would fail part way through
>> when it ran into the locked directory.
>>
>> As I recall I brought up the question of memory use when I introduced
>> the entries caching.
>
> Philip -- I don't understand... in the case of checkout/update, why
> would we ever get to a point where we're holding *every* entries file
> in memory?
It was deliberately coded that way, partly because it was the easy
thing to do, and partly because some of the operations made multiple
passes over the working copy. (Commit for instance scanned the wc
looking for targets, there was more wc access during the commit, and
then a final pass when storing auth info.)
> It would be nice if, in this case, our entries-caching used one
> subpool per directory. I mean, once the update-editor's close_dir() is
> called, couldn't we free an appropriate subpool containing the entries
> file. That way, at any given time, we'd only have one "path" worth of
> entries files cached in memory.
There certainly is scope for change, particularly since we no longer
store auth data in the working copy. It would mean giving up the
"lock the entire tree before starting" behaviour, as that involves
reading all the entries files and it's silly to do that and then
discard the entries data.
Commit might be more of a problem, since it must either hold the
entries in memory or reread the entries files when bumping the
revision post-commit. It might be possible to drop the entries for
those parts of the tree that are not involved in the commit.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 19 18:20:34 2003