On Tue, 2011-01-11 at 14:56 +0100, Bert Huijben wrote:
> > -----Original Message-----
> > From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> > Sent: dinsdag 11 januari 2011 14:44
> > To: Julian Foad
> > Cc: dev_at_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
Received on 2011-01-11 16:02:37 CET