Error reported with bzr check on a shared repository
Jurgen Defurne
jurgen.defurne at pandora.be
Fri Sep 4 17:13:53 BST 2009
On Thu, 03 Sep 2009 13:48:04 -0500
John Arbash Meinel <john at arbash-meinel.com> wrote:
>
> This is rather serious. Something has massively corrupted the file
> .bzr/branch-format
> And inserted random binary data...
>
> I honestly don't know what happened here, but it seems rather strange.
> If you aren't having any other problems, then likely you have just one
> branch somewhere which is broken with a bogus format file. Which may be
> safe to just delete. (I would create a backup copy before doing any
> deleting, though.)
>
Ok, shit happens sometimes. The repository was important, but the
branch inside it not so. I branched from all the branches in the
repository which did not gave an error, created a new repository and
pushed all freshly created branches inside it, doing a check after each
operation.
Backups are of course mandatory. I presume that for bzr the same rules
go as we use at our job for Continuus : first an integrity check and
then a nightly backup. However, how much I loathe Continuus, it seems
that it is more transparent and easy to recover from an integrity check
failure than for bzr. My boss did not have to do a restore from backup,
while I presume if something goes wrong in bzr, the safest bet is to
inform every body to keep their work, restore the repository from
backup and recommit everybodies work afterwards. Another thing that I
find better in Continuus is that, since it is built upon a real
database, there are certain atomic actions which are executed as
transactions. I do have problems with the fact that locks and
temporary directories can remain in the repository if for some reason
one needs to interrupt an operation. But this is a digression.
Am I content about bzr ? Yes, since I am currently migrating from svn
to bzr, after my svn repository got corrupted at version 615 while I
had already committed to version 625 (you could say backups, but in
this case my backup would also probably have been bad). However, I do
not think that in our case I would be ready yet to try to migrate bzr
for our main embedded software (complete tree = 6 Gb, with probably
1000 commits a week on average, and around 100000 objects, with
multi-site development. Btw, is there a way to add attributes to
objects in a bzr branch, a la subversion ?). I will try to recommend it
for tool and utility development, because it is much more lightweight
than Continuus. I think it would also be beneficial for our people to
have a working knowledge of other VCS's.
Regards,
Jurgen
More information about the bazaar
mailing list