[MERGE] unlock while in a write group now aborts the write group, unlocks, and errors.

[Martin Pool]

If unlock() is run (almost always from a finally block) and finds the
repository is still in a write group, it's better to abort the write
group and remove the lock.  The current code leaves the lock alive,
which seems unlikely to be useful.

This does have the disadvantage that the error raised about the write
group still being here is going to mask the previous error that
originally caused the unwinding - in fact, that's a problem generally
when an exception can be raised from a finally block.  It might be good 
for methods like unlock to log the previous sys.exc_info, or at least
log it if they encounter an error themselves.  Something for later...

To avoid losing that information, it probably is still better, as the
current code does, to explicitly call abort_write_group and re-raise
the previous error when unwinding.

This also changes RemoteRepository.lock, which was previously leaving
the remote repository locked if the _real_repository encountered a
problem in unlocking (such as still being in a write group.)

(This patch also has callCatchWarnings which was previously approved and
is now merging.)


-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bzr-mail-slJnbM.patch
Type: text/x-diff
Size: 16560 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071025/df955dbb/attachment.bin