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

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Alexander Belchenko wrote:
>> Basically you could just tar shared repo.
>> But potentially you can end up with incomplete history in some branch
>> if someone will try to commit when you try to backup. You may end up
>> with some junk info in the backup archive, locked repo/branch etc.
> 
>> IMO, safest way is to duplicate your shared repo with branches before
>> archiving, and delete after you created tarball.
> 
> This just changes the time when concurrent updates can produce an
> inconsistent repository.  Instead of worrying about someone committing
> while you're tarring, you worry about someone committing while you're
> duplicating.
> 
> If you're actually worried about concurrent updates (I'm not-- we do our
> backups when no one's working) then you need to lock your repository.
> 
> Here is a simple script allows you to run a command with your repository
> write-locked.
> 
> You use it like by specifying a path to your repository, followed by any
> arbitrary command.  e.g.
> 
> $ ./backup-repository /mnt/bzr/bzrrepo cp -r /mnt/bzr/bzrrepo/ mybackup
> 
> Aaron

The only downside to this is that you've backed up a locked repository, so the
first thing you need to do is "bzr break-lock" on it when restoring. But it is
a decent way to do it. And break-lock is a rather small thing. (it is similar
to making the backup readonly, which is a good thing.)

Another way is to keep an alternate repository and clone all branches into it,
and then back that up. Since that one is guaranteed to be offline. And we
guarantee consistency (even if push/pull is interrupted the data stays
consistent on disk). There would also be an order that you could copy the data
and get consistent results (copy all the branches, and then the repository,
starting with revisions, then inventory, then knits/*, and copying .kndx before
.knit).

It wouldn't be hard to write a script that built up the filenames in the right
order. If you go in that order, you will always have consistent data, even in
the middle of a push or pull. At worst, you just end up with some unreferenced
data sitting around.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHPbg+JdeBCYSNAAMRAuQFAJwIO/Rj77SXMVgRVpXXSi2qt/RL0QCcD0NP
J6YmF1KAv5DV7pSC6LBG/oo=
=WtU0
-----END PGP SIGNATURE-----