----- Original Message -----
> From: Branko Čibej <brane_at_apache.org>
> To: Ashod Nakashian <ashodnakashian_at_yahoo.com>
> Cc: "dev_at_subversion.apache.org" <dev_at_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
Received on 2012-04-01 09:53:44 CEST