[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