On Tue, 2011-01-11 at 14:56 +0100, Bert Huijben wrote: > > -----Original Message----- > > From: C. Michael Pilato [mailto:cmpil...@collab.net] > > Sent: dinsdag 11 januari 2011 14:44 > > To: Julian Foad > > Cc: dev@subversion.apache.org; Philip Martin; Hyrum K Wright > > Subject: Re: [PATCH in progress] Ref-counting for pristine texts > > > > On 01/11/2011 08:20 AM, Julian Foad wrote: > > > I'm not 100% sure whether close_wcroot() is the best place to delete > > > unreferenced pristines. Review of the concept would be useful here, > > in > > > comparison with other options such as deleting after flushing the > > work > > > queue or at some other place. > > > > Just throwing this idea out there: what if we didn't automatically > > delete > > the pristines, but instead marked them as unused and let 'svn cleanup' > > quickly purge the unused pristines? I'm thinking forward here to the > > day > > when our updates/switches/etc. get back from the server the skelta -- > > with > > checksums -- and the client has the option to fetch the file contents > > or > > locate it in the pristines area. More pristines to choose from means a > > better chance of local "hit". > > I see a different issue here: The close_wcroot() call is normally > handled from pool cleanup for users of the svn_client api. (The > svn_wc_context_t is cached in the client context, which is only closed > on pool cleanup).
Thanks for pointing that out. That is not when I would like the pristine cleanup to happen. I would like it to happen after every operation that changes the WC - say after every major call into libsvn_wc, and/or every major call into libsvn_client, or whenever the wc.db work queue is run. Any thoughts on where would be best? > When Subversion is used as a library we can't rely on when (or where) > this pool cleanup runs. In Java (javahl) and .Net (SharpSvn) this > could be the finalizer thread. We can't return error messages or call > callbacks from there. > > For these cases I would like to see the final cleanup phase optional. > > I certainly see cases where the cleanup here is useful, but I > certainly wouldn't like to see a blocking finalizer thread because it > has to perform a ton of network IO to cleanup some remote working copy > that was used some time ago. Sure. There's no need for an optional final clean-up phase; it should simply be invoked at an appropriately small granularity and never from the pool cleanup of a long-lived pool. - Julian
