[MERGE] repository write groups

[Robert Collins]

On Mon, 2007-07-30 at 11:02 -0400, Martin Pool wrote:
> Martin Pool has voted resubmit.
> Status is now: Resubmit
> Comment:
> Since this introduces a new fairly major concept it would be good to add
> something to HACKING (before merging, or we'll forget.)  Let me try and
> draft it and you can correct it:
> 
>    Write groups
>    ------------
> 
>    Some repositories support the concept of a write_group.

I'm requiring all repositories to use write_groups; for some its just
going through the motions, for others, like the pack based repository,
its core to how it works. So I'd say 'Repositories use the concept of a
write_group.'

>    These are created and returned by ``start_write_group``, and
>    concluded by either ``commit_write_group`` or
>    ``abort_write_group``.  A write lock must be held on the
>    repository for the entire duration.
>    At most one write group can be
>    active on a repository at a time.
> 
>    Write groups are different from write locks in that they explicitly
>    control when data is committed into the repository.  Several write
>    groups could be committed during a single lock.

Perhaps "Write locks provide a cache of repository data during the
period of the write lock, and allow write_groups to be acquired. For
some repositories the presence of a write lock is exclusive to a single
client, for others which are lock free or use server side locks (e.g.
svn), the write lock simply provides the cache context. Write groups
provide the window during which data is being inserted inside the larger
caching context.

There is no guarantee that data inserted during a write group will be
invisible in the repository if the write group is not committed. Some
repositories have an atomic insertion facility, and for those
all-or-nothing will apply."

>    The difference between Transactions and write groups is .... that
>    transactions are not part of the public api?

transactions are really about caching of data in memory, write groups
are about explicitly starting and finishing actual writes. 

> If they make promises about transactionality then can knit formats keep
> them?

They don't, because knits and others cannot.

>       def test_commit_message(self):
>           tree = self.make_branch_and_tree(".")
> +        tree.lock_write()
>           builder = tree.branch.get_commit_builder([])
>           self.record_root(builder, tree)
>           builder.finish_inventory()
>           rev_id = builder.commit('foo bar blah')
> +        tree.unlock()
>           rev = tree.branch.repository.get_revision(rev_id)
>           self.assertEqual('foo bar blah', rev.message)
> 
> The unlock should probably be in a finally in all these tests, even 
> though
> it's just a test, otherwise we may get open-file errors on Windows.  I
> guess we can stand that if it's a failing test, but still.

I deliberately don't do that because its just noise in the test - as
long as the failure is readable, its still a failure. 

> +        """complete a write group on the decorated repository.
> 
> Should have an initial capital (two occurrences.)

Will do.

> +    def start_write_group(self):
> 
> Could usefully say 'returns None', since you test for it - a reader 
> might
> expect it to give back a token or something.  Actually, maybe it should?

YAGNI. IF/when we want that we can code for it.

> > compatability
> 
> "compatibility", several times.

Will do.

-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/9df23f28/attachment-0001.pgp