grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [URGENT] Re: bazaar


From: Colin D Bennett
Subject: Re: [URGENT] Re: bazaar
Date: Tue, 24 Nov 2009 07:50:29 -0800

On Mon, 23 Nov 2009 02:19:24 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:

> Carles Pina i Estany wrote:
> > Hello,
> >
> > I have to go to sleep now, but I've realized about a mistake or at
> > least unexpected behaviour.
> ...
> Looks like the mess is actually more profound than you describe.
> You
> replaced our mainstream with your branch. Looks like bzr failed at its
> primary task: protect against unintentional or intentional  deletion
> of files.  We should think of a way to make trunks and experimental
> branch commit-only. Meanwhile nobody pushes until further notice.
> I'll see how it can be recovered and protected.
> Robert: What is your latest backup before this accidental replacement?

The ‘append_revisions_only’ option should probably be set for all
public branches to prevent accidental non-commit changes (i.e.,
pushing that would reorder revisions, since ‘push’ is really a
mirroring operation and can change revision numbers for existing
revisions).  Add ‘append_revisions_only = True’ to the
branch's .bzr/branch/branch.conf (or, for new branches, use the
--append-revisions-only option when creating the branch with bzr init).
See
<http://doc.bazaar-vcs.org/bzr.2.0/en/user-reference/#append-revisions-only>
 for details.

When append_revisions_only is set, pushing to trunk can be done, but
it won't alter existing revisions, so it will prevent problems.  You
can't use the 'uncommit' command then, of course, but that is by
design.  To revert a revision (e.g., revno 44) you would use 
'bzr merge -r 44..43 ; bzr commit' instead, as this is an appending
operation only.

Obviously a malicious user can corrupt the repository since the
SSH/SFTP transport we're using allows full raw file access for
committers, but it's the accidental mess-ups we are really concerning
ourselves with since we have to trust committers anyway--hopefully we
have frequent automated backups.  (It might be worthwhile looking into
using revision signing at some point though as well as an extra measure
of security; I haven't used Bazaar's revision signing yet.)

Regards,
Colin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]