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

RE: Purging pristines

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 28 Jul 2011 12:38:46 +0200

> -----Original Message-----
> From: Markus Schaber [mailto:m.schaber_at_3s-software.com]
> Sent: donderdag 28 juli 2011 11:20
> To: Julian Foad; Daniel Shahaf
> Cc: dev_at_subversion.apache.org
> Subject: AW: Purging pristines
>
> Hi,
>
> Von: Julian Foad [mailto:julian.foad_at_wandisco.com]
>
> > And IMO we should work on purging unused pristines automatically, for
> > 1.7.x if possible.
>
> I agree here that automatic purging of pristines is very useful, although you
> can do 1.7.0 without it for now (as manual purging is possible).
>
> > I'd like to see purging at a fairly fine-grained level. Does anyone have
> > insight about how to do this? What's in my head is that every WC API
> > operation that could possibly leave unused pristines should attempt to
> > purge unused pristines before returning. The operations that could leave
> > unused pristines are basically 'update' and 'switch', although there may
> > be some lower level WC API calls that can do so too. The set of pristines
> > to be purged could be either all that are currently unused, or just those
> > that became unused during the call.
>
> AFAICS, a "commit" operation may also produce unused pristines.

And at least crop, exclude, revert and delete can also produce unused pristines.
(Conceptually the first two by changing the BASE tree, the other two by changing the WORKING tree).

When we release pristines doesn't have to be the same between 'svn' and the other clients if we just create a libsvn_client function that cleans up pristines.
(And which doesn't break locks)

I think we should have at least some pristine cleanup which doesn't require user confirmation to verify if it is safe to steal locks.

I'm -1 on recommending users to script a 'svn cleanup' in their common usage patterns.

        Bert
Received on 2011-07-28 12:39:33 CEST

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.