Atomic operations.

[Martin Pool]

On 03/10/2006, at 13:28 , Tim Webster wrote:

> Hi,
>
> I don't know if a request for atomic operations has been made before.
>
> I see atomic operations, such as commit, and merge/update as very  
> important features. Particularly if the version controlled files  
> are in active use, it is essential that each file is changed in an  
> atomic mater. Possibly by building files in a tmp dir, than  
> atomically moving the files to replace version controlled files.   
> Also if the complete commit or merge did not run to completion, it  
> is important that this is reported by status. A command should be  
> available to roll back working flies to their state prior to the  
> incomplete commit or merge. Alternately the user could attempt  
> another commit or merge.

Hi Tim,

Commits are atomic in the sense that changes to all files are  
recorded as a unitary tree-wide revision.

When files in the working tree are updated, they are renamed into  
place as you describe, from what we call a "limbo" directory.

If commit doesn't complete, you will see all the changes still  
present in status.
If merge doesn't complete, you may be left with some files modified,  
but 'revert' will restore the previous revision and then you can try  
the merge again.  (This assumes you're following the recommended  
practice of starting from a clean tree before merging.)  If there's a  
substantial use case that's not covered then let's talk here about  
how that should work in detail.

> Also please point me to developer docs describing the format of the  
> bzr repository.

The best guide is the docstrings within the sourcecode, plus the  
HACKING file in the source tree.  There are probably some things  
we've picked up along the way which are not adequately described; if  
you hit some please ask on this list and we will fill you in and/or  
fix the docs.

Regards,
-- 
Martin