Received: from spf5.us4.outblaze.com (spf5.us4.outblaze.com [205.158.62.27]) by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id j192jghq011135 for ; Wed, 9 Feb 2005 02:45:42 GMT Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by spf5.us4.outblaze.com (Postfix) with ESMTP id C204C76EC8 for ; Wed, 9 Feb 2005 02:46:38 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cyi5F-00041C-5Y for migo@homemail.com; Tue, 08 Feb 2005 22:00:05 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyhyY-0001EC-GV for gnu-arch-users@gnu.org; Tue, 08 Feb 2005 21:53:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyhyH-000180-HT for gnu-arch-users@gnu.org; Tue, 08 Feb 2005 21:52:53 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyhyG-0000yp-7N for gnu-arch-users@gnu.org; Tue, 08 Feb 2005 21:52:52 -0500 Received: from [64.233.184.202] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyhUQ-0003VY-JZ for gnu-arch-users@gnu.org; Tue, 08 Feb 2005 21:22:02 -0500 Received: by wproxy.gmail.com with SMTP id 40so84778wri for ; Tue, 08 Feb 2005 18:22:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HIMlngpy5zHQak/OKwPW0T9vi2xaSGyqIMYaZvsP+CF8UP9ZVAcZIXcuJCiFYTHY2K7VlsotIgtTlzha3zfXaDpYOd2pMbKKgFTu/uftYbd3vg2xuYYl9kXQ+WSrlg8BrpQgwLEOx5vNSo2/NwWeCFlVRUXoPIkNyOkNVPlQx2k= Received: by 10.54.59.6 with SMTP id h6mr80098wra; Tue, 08 Feb 2005 18:22:02 -0800 (PST) Received: by 10.54.19.70 with HTTP; Tue, 8 Feb 2005 18:22:01 -0800 (PST) Message-ID: Date: Wed, 9 Feb 2005 11:22:01 +0900 From: Miles Bader To: gnu-arch-users@gnu.org Subject: Re: [Gnu-arch-users] Re: Making --setup default in tag and import In-Reply-To: <20050208232512.GA4503@benfinney.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050207184626.GB11858@ukato> <200502071913.LAA09656@emf.net> <87sm47i0d1.fsf-monnier+gmane.comp.version-control.arch.user@gnu.org> <4208DE97.40706@panoramicfeedback.com> <20050208231251.GA1604@ukato> <20050208232512.GA4503@benfinney.id.au> X-BeenThere: gnu-arch-users@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: snogglethorpe@gmail.com, miles@gnu.org List-Id: a discussion list for all things arch-ish List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org Status: RO Content-Length: 2047 Lines: 48 On Wed, 9 Feb 2005 10:25:13 +1100, Ben Finney wrote: > This then breaks the "one and only one [...] forever and ever" that > Aaron said, above. > > Once something has happened in the archive it *has happened*; any "undo" > or "redo" is a further change, recorded in addition to the original. > That's the model on which GNU Arch is founded; a deliberate design > decision. > > You seem to be suggesting technical "solutions" to subvert something > that is a fundamental part of the design of GNU Arch. Christ, can we be a bit more pedantic please? The "11th deadly sin", as used recently against arch :-): "11. to rate the beauty of mathematics above the usability of your compiler." This attribute of arch is great in general, but it only really _matters_ if someone has a dependency on the information in question. In practice, a command to delete stuff from a private local archive in certain cases would be a nice tool in a limited set of circumstances, and people would appreciate it. If such a command were actually offered by tla, it should try to automatically enforce safety (e.g., once if a branch/revision has been mirrored/checked-out, it shouldn't be deleted) and maybe implementing such enforcement is too annoying. But that's a practical decision. BTW, on the original subject, the idea that requiring -S is actually going to make it safer seems ... ludicrous. As has been pointed out, it will simply become an automatic part of such commands, a "--yes-really" option, and people will create bogus branches because of typos with exactly the same frequency as if there were no -S option. So while the question of whether certain archive deletions should be allowed is interesting, I'm not sure it really affects the issue of -S very much. -Miles -- Do not taunt Happy Fun Ball. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/