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.
Received on 2012-04-01 09:24:15 CEST