subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashod Nakashian <>
Subject Re: Compressed Pristines (Summary)
Date Sun, 01 Apr 2012 07:53:05 GMT

----- Original Message -----
> From: Branko Čibej <>
> To: Ashod Nakashian <>
> Cc: "" <>
> Sent: Sunday, April 1, 2012 12:23 PM
> Subject: Re: Compressed Pristines (Summary)
> On 31.03.2012 23:30, Ashod Nakashian wrote:
>>>>   Git can keep deleted items until git-gc is invoked, should we 
> support 
>>>  something similar, we need to be consistent and probably support 
> arbitrary 
>>>  revision history, which is out of scope.
>>>  I'm confused: how does revision history affect the pristine store?
>>  If the pristine store also keeps multiple revisions, then it's a whole 
> different set of features than what we are aiming for (at least for compressed 
> pristines).
> Certainly the pristine store keeps multiple revisions of files. After
> all, it's just a SHA-1 => contents dictionary, so every time you 
> "svn
> update," you'll get new revisions of files in the pristine store.

Sure. I meant multiple revisions of the same file. You're absolutely right, the PS tracks
SHA-1 and whether two files are revisions of the /same/ file or not isn't relevant. What I
meant to say is that if we are to have such a case, we probably need to add support for it
on the higher level where files/revisions/SHA-1's/references are tracked. This is out of scope
and changes the very definition of the PS as we have it now.

> What the store doesn't do is /know/ about the revisions. Neither does
> the wc.db, which only tracks reference counts for the SHA-1 keys. Every
> time a file changes, its hash will change, too, a new key will be
> inserted in the pristine store, and the reference count for the old key
> will be decremented. I'm not sure what happens when the count reaches
> zero; used to be that only "svn cleanup" would delete unreferenced
> pristines, but ISTR this changed a while ago.
> In any case, the pristine store shouldn't worry about revisions, only
> about efficiently storing the contents. It doesn't even have to worry
> about reference counting, since wc.db already does that.
> -- Brane
> P.S.: If we ever implement local snapshots and/or local branches, it
> /still/ won't be the pristine store's problem to track whole-tree info.
> This is why I like the clear separation between pristine store, which is
> a simple dictionary, and wc.db, which is moderately complex.
> P.P.S.: When we transition from pristine store per working copy to
> pristine store per ~/.subversion directory, then the pristine store will
> have to track how many working copies are using it. But that's way in
> the future -- and another good reason to use a proper database for the
> indexing.

Sure. We're on the same page here on all points.


View raw message