Received: from spf5.us4.outblaze.com (spf5.us4.outblaze.com [205.158.62.27]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id iAG1Mwfs001332 for ; Tue, 16 Nov 2004 01:22:58 GMT Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by spf5.us4.outblaze.com (Postfix) with ESMTP id 8DE47773E4 for ; Tue, 16 Nov 2004 01:22:56 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTsCL-0005EB-MR for migo@homemail.com; Mon, 15 Nov 2004 20:31:57 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CTsC1-0005E2-AU for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 20:31:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CTsC0-0005Di-Mb for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 20:31:36 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CTsC0-0005DY-JV for gnu-arch-users@gnu.org; Mon, 15 Nov 2004 20:31:36 -0500 Received: from [202.32.8.214] (helo=tyo201.gate.nec.co.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CTs32-0004Ig-Bz; Mon, 15 Nov 2004 20:22:20 -0500 Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id iAG1MEa14633; Tue, 16 Nov 2004 10:22:14 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id iAG1MDP05509; Tue, 16 Nov 2004 10:22:13 +0900 (JST) Received: from edsgm01.lsi.nec.co.jp ([10.50.208.11]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id iAG1MC414504; Tue, 16 Nov 2004 10:22:12 +0900 (JST) Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edsgm01.lsi.nec.co.jp (8.12.10/8.12.10) with ESMTP id iAG1MAAY025991; Tue, 16 Nov 2004 10:22:11 +0900 (JST) Received: from mctpc71 (mctpc71.ucom.lsi.nec.co.jp [10.30.118.121]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id iAG1M9wt026362; Tue, 16 Nov 2004 10:22:09 +0900 (JST) Received: by mctpc71 (Postfix, from userid 31295) id 7889E441; Tue, 16 Nov 2004 10:22:09 +0900 (JST) To: John A Meinel References: <20041115180848.E16278@mofo.meme.com> <41994E33.7000903@arbash-meinel.com> From: Miles Bader System-Type: i686-pc-linux-gnu Blat: Foop Date: Tue, 16 Nov 2004 10:22:09 +0900 In-Reply-To: <41994E33.7000903@arbash-meinel.com> (John A. Meinel's message of "Mon, 15 Nov 2004 18:47:47 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: gnu-arch-users@gnu.org, "Karl O. Pinc" Subject: [Gnu-arch-users] Re: FYI, More arch errors while grying to commit 'clean changesets' X-BeenThere: gnu-arch-users@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Miles Bader 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: 1824 Lines: 40 John A Meinel writes: > Partial commits don't support add/delete/rename. The problem is with a > partial commit you can't tell the difference. For example: I think there are various possible ways of supporting these operations in partial commits, it's just that there's no agreement on what's "best" (the last time I remember it being discussed, there was an awful lot of waffling), and of course nobody has implemented them. The one I like is to automatically extend the limit to include the other half of a rename; I think in the usual case, this could be done without a full inventory by doing an id->name lookup of every specified file in the revision library's ,,index file. E.g., in your example: > $ tla mv file2.txt file3.txt > $ tla commit "moved file2.txt" -- file3.txt If the orig version had file-id "XYZ" for file1.txt, and "PQR" for file2.txt, the commit command would lookup the orig name for "file3.txt" by using it's file-id "XYZ", find file1.txt, and act as if the user had specified: tla commit ... -- file1.txt file3.txt [Of course this procedure iterates until the limit cannot be extended anymore.] I think for the vast majority of cases this is what the user wants. A more-annoying-but-possibly-safer alternative is to use the above procedure to check the limit for completeness, and abort with an error if there were any renames across the limit boundary. Then the user could commit renames by being sure to manually specify both the old and new names. -Miles -- My spirit felt washed. With blood. [Eli Shin, on "The Passion of the Christ"] _______________________________________________ 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/