From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NCxf5-0001ip-L3 for mharc-grub-devel@gnu.org; Tue, 24 Nov 2009 10:50:39 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCxf4-0001i6-Ip for grub-devel@gnu.org; Tue, 24 Nov 2009 10:50:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCxf2-0001gZ-Ov for grub-devel@gnu.org; Tue, 24 Nov 2009 10:50:38 -0500 Received: from [199.232.76.173] (port=50240 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCxf2-0001gQ-I1 for grub-devel@gnu.org; Tue, 24 Nov 2009 10:50:36 -0500 Received: from gator297.hostgator.com ([74.53.228.114]:47532) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NCxf2-0005wk-6a for grub-devel@gnu.org; Tue, 24 Nov 2009 10:50:36 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gibibit.com; h=Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type; b=FRk4AKHLR2YZRQtSAwsg2+AzMss1Km2A+bGAdcuH/MOQbzCbyk0RP+VS9zF7NoU0fup1lDsG9xhAf+6cuq4Q6ZqkOhUdth4VrT4oWa57Qw4yJHr0x0FJHl0cv6IH7/IX; Received: from c-67-185-87-185.hsd1.wa.comcast.net ([67.185.87.185]:45935 helo=svelte) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NCxez-0005y8-BZ; Tue, 24 Nov 2009 09:50:33 -0600 Date: Tue, 24 Nov 2009 07:50:29 -0800 From: Colin D Bennett To: The development of GNU GRUB Message-ID: <20091124075029.34723a43@svelte> In-Reply-To: <4B09E31C.7070207@gmail.com> References: <20091123004418.GA14340@pina.cat> <4B09E31C.7070207@gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/w.9SzwpB0DZEaQ1VE2nr+Gd"; protocol="application/pgp-signature" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: phcoder@gmail.com, Robert Millan Subject: Re: [URGENT] Re: bazaar X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:50:38 -0000 --Sig_/w.9SzwpB0DZEaQ1VE2nr+Gd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 23 Nov 2009 02:19:24 +0100 Vladimir '=CF=86-coder/phcoder' Serbinenko 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 =E2=80=98append_revisions_only=E2=80=99 option should probably be set f= or all public branches to prevent accidental non-commit changes (i.e., pushing that would reorder revisions, since =E2=80=98push=E2=80=99 is reall= y a mirroring operation and can change revision numbers for existing revisions). Add =E2=80=98append_revisions_only =3D True=E2=80=99 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 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=20 '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 --Sig_/w.9SzwpB0DZEaQ1VE2nr+Gd Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksMAMUACgkQokx8fzcGbYcCwQCfecplrtQerMKyIO8ilypbo8bT ymkAnjt8tf1kjfxMHSBs+jyVf7mg9byS =9qES -----END PGP SIGNATURE----- --Sig_/w.9SzwpB0DZEaQ1VE2nr+Gd--