What is a safe way of backing up a shared bzr repository
Vincent Ladeuil
v.ladeuil+lp at free.fr
Fri Nov 16 16:07:02 GMT 2007
>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:
<snip/>
john> The only downside to this is that you've backed up a
john> locked repository, so the first thing you need to do is
john> "bzr break-lock" on it when restoring. But it is a
john> decent way to do it. And break-lock is a rather small
john> thing. (it is similar to making the backup readonly,
john> which is a good thing.)
john> Another way is to keep an alternate repository and
john> clone all branches into it, and then back that
john> up. Since that one is guaranteed to be offline. And we
john> guarantee consistency (even if push/pull is interrupted
john> the data stays consistent on disk). There would also be
john> an order that you could copy the data and get
john> consistent results (copy all the branches, and then the
john> repository, starting with revisions, then inventory,
john> then knits/*, and copying .kndx before .knit).
john> It wouldn't be hard to write a script that built up the
john> filenames in the right order. If you go in that order,
john> you will always have consistent data, even in the
john> middle of a push or pull. At worst, you just end up
john> with some unreferenced data sitting around.
That screams "supported in core" to my ears.
So that both points above can be addressed:
- creating a read-only backup (or not)
- saving files in order to allow concurrent updates while
providing a usable backup
bzr branch already provide a way to backup a branch and a working
tree can be backed up like any tree, so providing a way to backup
a shared repository seems to be the only missing bit.
Vincent
More information about the bazaar
mailing list