bzr too slow

[Martin Pool]

On 11 Jan 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:

> I'm also not 100% satisfied with running a lot of operations in
> unlock(), since unlock is generally run as:
> 
> lock()
> try:
>   do stuff
> finally:
>   unlock()
> 
> Which means that unlock() should never raise, because it would mask the
> real exception.
> What we are doing right now is a hack because we know unlock() is always
> called. And we don't have a good place to put deferred actions.
> And hashcache is hidden inside WorkingTree, so the upper layer that
> knows when it is done with WorkingTree, doesn't know that there is a
> hash-cache which might need to be flushed to disk.

Much as in the mini-transactions of AtomicFile, I think you will want
one method called on successful completion, and another called to
dispose of it whether successfully completed or not.  This second one
will run rollback/abort type of operations.

> And we don't trust __del__ methods, which is where I would put this sort
> of code in C++.

Right, stack-allocated RAII would work quite nicely for some of these.

> Having Transaction with a queue of things to do at cleanup isn't
> terrible. But Robert is the one who knows what the plan is for
> Transaction. (He wrote it in the first place.) So he seems like a good
> source for final decisions on how it should change.

Yes, I also think the general idea of being able to do several things is
pretty reasonable (which is why i originally approved it.)

One reason to do the small change for now is that this is important
enough to go into 0.7, and I'd like fairly small changes after the rc1.

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060112/9eada116/attachment.pgp