General question regarding interrupting bzr operations

[John Arbash Meinel]

Nicholas Allen wrote:
> Hi,
> 
> After experiencing this problem with interrupting pull I was wondering
> if there may be similar problems in merge. Do you think that a power
> failure in the middle of a merge could leave a branch in a messed up
> state that it could not recover from? Just wondering if there would be a
> way to repair a branch in this happened? Are there test cases that
> simulate this scenario and is bzr generally designed to handle these
> kinds of problems?
> 
> Thanks,
> 
> Nick
> 
> 

The bzr storage format is designed in a layered structure, so that
interrupting it in the middle of operations (like a power-outage), don't
actually break anything in the data.

What *might* happen is some data gets written that doesn't get
references, so a future action will have to write it again. But there is
no corruption.

On Windows we have a slightly smaller guarantee, because Windows doesn't
support POSIX rename semantics (you can't rename a file over another
existing file, and if a file handle is open you can't do anything to the
file, delete, rename, etc).

So we have code which does:

  def rename(src, dest):
    mv dest => dest.tmp
    try:
      mv src dest
    except: # Failure
      mv dest.tmp dest
    else:
      rm dest.tmp

Which is ^C safe, but not power-outage safe. Fortunately, we only use
this property on non-critical files. (IIRC, revision-history which is a
cached lookup of the current history of a branch).

All of the other files are written in append-only mode. And the data is
written before the index, and all data files are written before the
inventory is written, etc.

It *is* possible that while merging you have your tree in a
half-modified state, and the power goes out. A 'bzr revert' will restore
things to before the merge, and you can just issue 'bzr merge' again to
try again.

The only time I'm aware of a problem is 'bzr pull' when you have
uncommitted changes in your working tree. (Technically 'bzr merge
--force' would have the same problem, but by default merge won't let you
merge if there are uncommitted changes).

Anyway, in that circumstance, pull will merge the remote changes into
the working tree, even though you have local changes. So it is possible
that the merge would half-succeed, power goes out, and then your local
changes are mixed in weird ways with an incomplete merge of the remote
changes.

Also, we currently have a bug because Windows doesn't let you modify a
file if it is being held open by another process (like certain editors,
but not all). Which means the merge can be halted in the middle of
operating. My recommendation would be to catch that sort of error, and
continue with the rest of the merge, warning the user that a specific
file could not be updated. (And we would want some way to update that
file). Or we could abort the whole operation, and rollback the other
files, but that is not as nice.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061031/8e585bfb/attachment.pgp