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