[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Re: Flushing directory log accumulator during pool cleanup (Re: svn commit: r23342 - trunk/subversion/libsvn_wc)

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2007-11-06 15:49:32 CET

"David Glasser" <glasser@davidglasser.net> writes:

> On 11/6/07, Philip Martin <philip@codematters.co.uk> wrote:
>> Philip Martin <philip@codematters.co.uk> writes:
>> > 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?
>> A crude test shows that trunk uses a little bit more memory than 1.4
>> but is faster, I'm happy with that.
> So to clarify: you'd be OK with just applying the patch as posted? Or
> should I implement the idea of adding a boolean which represents
> whether or not the buffer is flushable?

I'm happy with the memory/speed tradeoff made by trunk. I don't know
for certain what behaviour the existing code has or what behaviour
your patch gives. I'd not be happy if after watching 1500
notifications "A somefile" scroll past that a failed network
connection, or user interrupt, means that those 1500 files vanish.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 16:09:50 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.