Re: Compressed Pristines (Summary)

[Branko Čibej <br...@apache.org>]

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.

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.

Re: Compressed Pristines (Summary)

[Ashod Nakashian <as...@yahoo.com>]

----- Original Message -----
> From: Branko Čibej <br...@apache.org>
> To: Ashod Nakashian <as...@yahoo.com>
> Cc: "dev@subversion.apache.org" <de...@subversion.apache.org>
> 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.

-Ash