> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: woensdag 26 januari 2011 19:11
> To: Branko Čibej
> Cc: dev_at_subversion.apache.org
> Subject: Re: Ref-counting for pristine texts
>
> Can anyone help me work out the rules for guaranteeing consistency of
> the pristine text store?
>
>
> On Wed, 2011-01-19, Branko Čibej wrote:
> > On 18.01.2011 16:58, Julian Foad wrote:
> > > On Thu, 2011-01-13, Branko Čibej wrote:
> > >> This would indicate that the reference counting happens too soon ... in
> > >> other words, that a pristine can be dereferenced whilst some part of
> the
> > >> code (or database) still refers to it. That breaks database consistency
> > >> -- what happens if the user aborts a commit and then calls 'svn
> > >> cleanup', for example?
> > >
> > > If what I said about 'commit' is correct, then yes, that's bad and we
> > > should look for a better way. But I haven't tested it properly; I
> > > noticed that the commit failed saying that the DB failed a 'REFERENCES'
> > > clause, and what I said here is a hypothesis about how that happened.
> [...]
>
> I've had a chance to look at this now. What happens now is
> svn_client_commit5() does this:
>
> svn_client__do_commit()
> # Among other things, for each file being committed, this
> installs into the pristine text store a version that will
> later be referred to as the new base version, and returns
> the SHA1 checksum of that.
>
> if the commit succeeded:
> for each committed item:
> post_process_commit_item(..., item->sha1_checksum)
> # This changes the WC DB to reference the SHA1 checksum
> of the new pristine text.
>
> The problem is that after svn_client__do_commit(), the new pristine
> texts are in the store but unreferenced.
>
> We need to decide on the rule that determines at what times the
> reference counts can be assumed correct.
>
> * Always correct outside a DB txn?
Previously we used a somewhat reversed definition: as long as there are work queue items or working-copy locks, you can't assume pristines are unreferenced.
Note that there can be multiple clients accessing/modifying a working copy at the same time even though they don't have a sqlite transaction open. (An update doesn’t keep it's transaction open for the entire update process).
Bert
Received on 2011-01-26 21:03:26 CET