Philip Martin wrote:
>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.)
>
>
If I remember correctly, this was a huuuuge performance win, as
import/commit profile times used to be spending around 70% of its time
in the XML read/write code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 19 20:30:04 2003