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 i9PL8mmX008963 for ; Mon, 25 Oct 2004 21:08:48 GMT Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by spf5.us4.outblaze.com (Postfix) with ESMTP id EEE4976F83 for ; Mon, 25 Oct 2004 21:08:47 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMCCo-0008TN-PL for migo@homemail.com; Mon, 25 Oct 2004 17:16:42 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMCCI-0008S9-Hh for gnu-arch-users@gnu.org; Mon, 25 Oct 2004 17:16:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMCCH-0008R0-9X for gnu-arch-users@gnu.org; Mon, 25 Oct 2004 17:16:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMCCG-0008Qf-PV for gnu-arch-users@gnu.org; Mon, 25 Oct 2004 17:16:09 -0400 Received: from [209.158.45.74] (helo=linuxguru.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CMC4Y-0005t4-Ka for gnu-arch-users@gnu.org; Mon, 25 Oct 2004 17:08:10 -0400 Received: by linuxguru.net (Postfix, from userid 10) id 02E2A3B4028; Mon, 25 Oct 2004 17:08:09 -0400 (EDT) Received: by comet.merconline.com (Postfix, from userid 1000) id DC05FB7D92; Mon, 25 Oct 2004 17:07:24 -0400 (EDT) Date: Mon, 25 Oct 2004 17:07:24 -0400 To: gnu-arch-users@gnu.org Message-ID: <20041025210724.GA19744@merconline.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: jblack@merconline.com (James Blackwell) Subject: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal X-BeenThere: gnu-arch-users@gnu.org X-Mailman-Version: 2.1.5 Precedence: list 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: 1918 Lines: 48 Hi guys, I keep thinking about the part of Tom's release proposal as it relates to patch-log pruning. I can't quite get my mind around the log pruning. As I understand things, this will make foreign trees difficult, if not impossible to manage. The problem goes along these lines. First, assume trees A, B and C. B regularly merges from A, but in the process prunes the patch-logs. C replays/updates/star-merges from B. Things still look reasonably sane, right? But now imagine what happens if C attempts to replay from A after replaying from B. C is going to end up in a pretty big mess, because without those patchlogs, C doesn't realize that the patches have already been applied, tries to apply the same patches twice, and then *boom*. What's this mean? This means that C can replay from either B or A, _but not both_. To do so would end up with conflicts up the yingyang. Though I think the intent is just to clean out old cruft (too many patch logs do slow down the tree a bit), it seems to me that it also unintentionally results in one of two possibilities: Either power is centralized in B, or B and C are precluded from working together if both happen to take revisions from external sources. Hopefully I'm missing something obvious, because if I'm not, then this would be a terrible direction in which to take arch, because it would prevent closely related branches from maintaining a close relationship... i.e. it would encourage arch to diverge, rather than converge. -- James Blackwell Try something fun: For the next 24 hours, give Smile more! each person you meet a compliment! GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D 247A 8A55 DA73 0635 7400 _______________________________________________ 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/