"David Glasser" <glasser@davidglasser.net> writes:
> On 11/5/07, Philip Martin <philip@codematters.co.uk> wrote:
>> "David Glasser" <glasser@davidglasser.net> writes:
>>
>> > On 11/5/07, Philip Martin <philip@codematters.co.uk> wrote:
>> >>
>> >> Your alternate implementation sounds much better: as I understand it
>> >> your proposed patch means that if a large update is interrupted there
>> >> could be lots of log "files" in memory corresponding to megabytes of
>> >> downloaded data and effectively all this data would be lost.
>> >
>> > That's true.
>> >
>> > On the other hand, if you're interrupting an operation, do you really
>> > want megabytes worth of work to be done before the process finishes?
>>
>> I think yes. As I understand it the log files are mainly about moving
>> stuff into place from the tmp directory and updating the entries file,
>> that's relatively quick compared to downloading large amounts of data.
>
> Hmm. I'll believe you speed-wise (though there are a bunch of things
> that modify entries files),
I'm not sure what you mean by "a bunch of things".
> but if I'm trying to kill something
> doesn't that mean I want it to stop, and not keep doing more things?
What are these things that are getting done? Do you think it is
correct to abandon files that have been downloaded?
The original change raises a few questions: suppose a directory
contains 2000 files (I think GCC's ADA directory is about this size),
does the client now hold 2000 logfiles in memory? How much memory
does that take? Perhaps we should limit the number of log files held
in memory?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 02:47:41 2007