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

Re: [PATCH in progress] Ref-counting for pristine texts

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Tue, 11 Jan 2011 09:02:29 -0600

On Tue, Jan 11, 2011 at 8:07 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 01/11/2011 09:01 AM, Mark Phippard wrote:
>> On Tue, Jan 11, 2011 at 8:43 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> 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?
>>
>> Isn't that how it works now?  Here is Julian's message that started this thread:
>>
>> "The current situation without this work is that many pristine texts
>> are not deleted when they become unreferenced, and they accumulate in
>> the pristine store until the user runs "svn cleanup".  I think that is
>> not good enough even for an initial release."
>
> I overlooked this part of Julian's mail, and ignorantly figured we were just
> accumulating unused pristines today.  But the salient point of my mail
> stands:  maybe that's not necessarily a bad thing.  I mean, if folks are
> cool with letting a DVCS tool cache a whole stinkin' repository on their
> disk(!), what's a relatively small number of extra pristines?

Most DVCS use some crazy compression for storing the blob contents of
the repo, whereas we don't use *any*. However, these systems usually
do require a additional, out-of-band command to do the compression.

-Hyrum
Received on 2011-01-11 16:03:08 CET

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.