[MERGE] repository write groups
John Arbash Meinel
john at arbash-meinel.com
Fri Jul 20 17:46:07 BST 2007
John Arbash Meinel has voted +1 (conditional).
Status is now: Conditionally approved
Comment:
I like the idea of write groups, though it seems a little bit redundant
with our current Transaction code.
I believe the idea is that you want to get rid of our "lock + implicit
commit at unlock" and make it more of a "start + explicit commit and
finish | explicit rollback with abort".
+ try:
+ # don't need a specific exception for now - this is
+ # really to be sure it's used right, not for signalling
+ # semantic information.
+ self.assertRaises(errors.BzrError, repo.start_write_group)
+ finally:
^- I think you *do* want an explicit (AlreadyInWriteGroup) or some other
clear error.
It isn't quite clear to me who gets to decide when to start the write
group, since now you are having the transaction start/end be
non-reentrant. Are you trying to make low-level functions just assert
that we are in a write group, and high-level ones must take a write
group?
The only problem with that, is that I believe there are some code paths
which are called directly *and* are called as children functions from
some other main-level action.
I can't guarantee that, but I know when I was trying to fix the progress
bars for 'bzr branch' and 'bzr pull' I ran into the fact that they
execute the same 'fetch()' process, but with a different number of
layers above it. So getting the progress right for one of them, meant
that the other one exposed too much, or too little information.
For details, see:
http://bundlebuggy.aaronbentley.com/request/%3C1184806331.11842.41.camel%40localhost.localdomain%3E
More information about the bazaar
mailing list