What is a safe way of backing up a shared bzr repository
Hans Fangohr
h.fangohr at soton.ac.uk
Mon Nov 19 11:04:42 GMT 2007
Dear all,
many thanks to all that have responded to my question.
I try to summarise the replies (but be aware that I have just started
learning about bzr; so this may be inaccurate)
- if I just copy the file structure (i.e. the .bzr directories), I
could get an inconsistent copy if somebody is commiting while I copy.
(Not an option for me).
- I could 'lock' the repository with the script provided by John
(thanks!), then make the copy. This is a 'clean' solution in that it
always works (in the sense of creating a consistent copy) but if I
ever have to use the backup, I need to unlock it first.
- I could create a clone and create a copy of this. (No idea what a
clone is but that can probably be learned from the bzr documentation).
- I could copy the files in the right order (not really something I
would like to do unless the bzr team provides the script for this).
So it seems there are options to create a safe backup. However, 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. Which of the methods listed above
would be used is mostly irrelevant to users like myself. As a former
svn user, I would look for a script called hot-backup.py -- but that
is of course a matter of taste and history.
What is the recommended way to suggest this feature?
Many thanks,
Hans
>>>>>> "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
>
>
>
>
--
Hans Fangohr
School of Engineering Sciences
University of Southampton
Phone: +44 (0) 238059 8345
Email: fangohr at soton.ac.uk
http://www.soton.ac.uk/~fangohr
More information about the bazaar
mailing list