From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel,gmane.comp.version-control.bazaar-ng.general Subject: Re: Emacs Bazaar repository Date: Fri, 14 Mar 2008 13:12:48 -0700 Message-ID: <47DADC40.4090209@emf.net> References: <87skyvse7k.fsf@xmission.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205523277 21575 80.91.229.12 (14 Mar 2008 19:34:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 19:34:37 +0000 (UTC) Cc: Andreas Schwab , Jason Earl , emacs-devel@gnu.org, bazaar@lists.canonical.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 20:35:05 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JaFg7-0003TC-1X for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 20:34:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaFfX-0008Rj-ET for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 15:34:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JaFfR-0008NL-DD for emacs-devel@gnu.org; Fri, 14 Mar 2008 15:34:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JaFfP-0008JF-EC for emacs-devel@gnu.org; Fri, 14 Mar 2008 15:34:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaFfO-0008IM-Th for emacs-devel@gnu.org; Fri, 14 Mar 2008 15:34:10 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JaFfO-0004bd-M4 for emacs-devel@gnu.org; Fri, 14 Mar 2008 15:34:10 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 25496631; Fri, 14 Mar 2008 12:34:06 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:92607 gmane.comp.version-control.bazaar-ng.general:38610 Archived-At: Stefan Monnier wrote: > Even if we end up using this tree to generate the initial Bzr tree, I'd > be interested to know who to add merge info to a Bzr repository. > > This is a frustrating development, from my perspective. Arch was designed to *not* be monolithic, in some specific ways that are relevant to problems like this: Arch defines a "global name-space" for projects, branches, and revisions -- but the idea is that you can use that name-space without using all of Arch. Users disliked a few superficial attributes of the Arch name-space but the basic idea of having one is sound. Without picking a specific DVCS, one can still pick a distributed, global name-space for revisions. Arch records merge history in the source tree itself, using ordinary files, referring to that global name-space. The source tree, not some external database, tells you what has been merged into a given revision. So, again, you can use Arch's way of recording merge history even if you don't use Arch itself. In practice, it's like having a Changelog but an extra-fancy changelog that tells you (or the merge tools you use) the merge history. All that the underlying DVCS has to do is make it possible to look up various trees (or deltas between them) using the global names. If you start with those two things, global names for revisions and in-tree merge-history, then your perspective on distributed revision control should change completely. For example, merge operations need not any longer be some built-in facility of the revision control system. Rather, merge operations are, by definition, algorithms that do some diffing and patching by looking at in-tree merge history and comparing various trees that are named there. A merge operator can be coded abstractly, in a way that works across multiple revision control systems. If a project like emacs, instead of picking a DVCS, picks a naming convention for revisions and a representation convention for merge history, then portability between DVCS systems becomes a largely moot issue. -t