What is a safe way of backing up a shared bzr repository

[Ian Clatworthy]

Aaron Bentley wrote:
> Hans Fangohr wrote:
> 
>> I agree with Vincent: bzr should really provide a simple script (and a
>> short section in the manual) that provides exactly this
>> functionality. Ideally, this would create a (consistent) copy of the
>> repository in a different place.

Yes.

> So it seems we have several options here:
> 
> First, delivery:
> 1. command
> 2. script
> 
> It's rare for us to provide scripts when we can provide commands
> instead.  I'm not terribly keen on introducing new commands, as some
> people use the length of the command list as a metric for deciding how
> easy a tool is to use.

I'd prefer a command. I see (and agree with) your point re command list
length but I'm against artificially lowering it (by making the command
hidden) for the sake of it. Backing up a repo is a genuinely "common"
Use Case, it needs to be documented, and explaining common stuff as 'use
hidden command xxx' feels wrong.

Perhaps we need to "clean out" the public command list if we feel the
length is too long? For example, renames and ignored could become hidden
with the documented way of finding that information being via ls, say.

> Next, scope:
> 
> Option 1: lock-and-foo
> This is basically what my script provided.  It allows any arbitrary
> command to be run with a locked repository.
> 
> Option 2: lock-and-copy
> This folds the copying into part of the script, e.g. with shutil.copytree
> 
> Option 3: lock-and-fetch
> This uses the appropriate bzr facilities such as fetch to produce (or
> update) a mirror of the repository.  This has the advantage of
> potentially working over remote transports, including the smart server.
>  But the remote transport must be listable in order for Bazaar to
> discover branches.  This option is typically much slower than the others.
> 
> Further thoughts?

I really like option 1. It's a pretty powerful feature to say "this will
lock your repository in a consistent state so you can do what you want
safely". As well as copying content for backup purposes, I can see it
being useful for other things teams may wish to do. Perhaps options 2
and 3 could be provided via options or sample scripts?

Ian C.