[MERGE] repository write groups

[Robert Collins]

On Mon, 2007-07-30 at 22:16 -0500, Martin Pool wrote:
> On 7/30/07, Robert Collins <robertc at robertcollins.net> wrote:
> 
> > > Is it just an entirely optional hint that some related writing is
> > > being done?  Or is the caller making a promise to the repository, or
> > > vice versa?
> >
> > The caller is not able to insert data outside the write group, so the
> > repository is promising to allow data insertion during the group.
> 
> Great, so say that!  "You are only allowed to insert data into a
> repository during a write group", if that's the case.

I'll add that to the docstring for start_write_group. I do think they
should be fully self explanatory without needing external docs outside
the API docs.

> > On some repositories a write lock is a mutex, because of the performance
> > impact of doing reads after a write has occured - e.g. weaves, where
> > writing reorganises large amounts of data. On others, like the one I'm
> > working on, or on svn, the write lock can become fictional, with actual
> > mutex's occuring during data insertion. E.g. I plan for
> > commit_write_group on pack repositories to be something like:
> > write out indices
> > take out a physical lock on the repository
> > allocate a name for the new pack
> > rename the pack and indices into place
> > release the physical lock
> 
> So it does sound a bit like this is really the write group, and it
> should implicitly take (or increment) a write lock if necessary.  "I'm
> starting writing... I'm done."

Uhm not really.

Consider commit:
lock_write
start_write_group
read basis data and per file graph data and so on while we
 - insert texts for new file versions
 - insert an inventory
 - insert a revision
 - insert a signature
** at this point all the new non index data is in a temporary pack file.
commit_write_group
 - finalise indices
** at this point all new data is in temporary files
 - physical lock taken
 - name allocated
 - new data renamed into place
 - physical lock removed
use new revision data for post commit actions like sending emails,
updating the basis inventory in the working tree
unlock

If you are saying 'start_write_group should do self.lock_write()', I
don't think so. Maybe I'm wrong but it doesn't line up all that closely.

> > > Not closing files (even in failure cases, iirc) caused pain for people
> > > testing on Windows and I don't see why this is any different.
> >
> > not closing files can cause errors in success cases; and also can have
> > the file object open in the traceback stack frames in error cases. This
> > is different because there are no physical resources kept open to cause
> > operating system level errors.
> 
> Yes there are, the lock file held by WT4.
> 
> And just generally, I don't think we want to rely on being able to
> delete a wt while it's locked.

Ok, I'll correct those. New patch coming shortly.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070731/780a4506/attachment.pgp