From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 552A5BB81 for ; Wed, 22 Dec 2004 00:19:44 +0100 (CET) Received: from mail.davidb.org (adsl-64-172-240-129.dsl.sndg02.pacbell.net [64.172.240.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iBLNJgN3016935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Dec 2004 00:19:43 +0100 Received: from davidb by mail.davidb.org with local (Exim 4.42 #1 (Debian)) id 1CgtI4-0005SG-EM; Tue, 21 Dec 2004 15:19:40 -0800 Date: Tue, 21 Dec 2004 15:19:40 -0800 From: David Brown To: Erik de Castro Lopo Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] [OT] Rant about VCS: Conclusions Message-ID: <20041221231940.GA20770@old.davidb.org> References: <41C3126A.3060101@barettadeit.com> <20041217213753.GA2295@pegasos> <20041218092716.18ca0ed7.ocaml-erikd@mega-nerd.com> <41C7E7EE.6030709@barettadeit.com> <41C89DB2.4020105@orcaware.com> <20041222093627.5a5376a3.ocaml-erikd@mega-nerd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041222093627.5a5376a3.ocaml-erikd@mega-nerd.com> User-Agent: Mutt/1.5.6i X-Miltered: at nez-perce with ID 41C8AF8E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 caml-list:01 wrote:01 unmanageable:01 model:01 merging:01 conflicts:01 embrace:98 tree:02 implementors:02 tend:02 instances:02 declaring:02 tricky:02 patches:02 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.0 X-Spam-Level: On Wed, Dec 22, 2004 at 09:36:27AM +1100, Erik de Castro Lopo wrote: > Arch OTOH keeps a log of all changesets applied to a tree. That > means that if you have three branches A, B and C, all with the same > common ancestor you can merge A -> B and then B -> C. Now if you > try to merge A -> C Arch is clever enough to figure out which > changesets in A have already been applied to C and which ones > haven't, and then only apply the ones that have not been applied. As far as I know, Arch and darcs are the only reasonably popular SCMs that keep track of merge history sufficiently. (I know nothing about BK, since I'm not allowed to run it, it probably does track this correctly). PRCS was probably the first to popularize this level of tracking of changes. It is a deeper issue than just knowing which changes to apply. When you have two active branches where changes propagate between them (common when there are two active branches), a solution other than Arch, or darcs quickly becomes unmanageable. The solution with most other SCMs is to just not do this, but it is a realistic scenario, especially when there are specific "customers" for specific releases. Darcs and Arch take very different approaches. Arch approaches this from a 'patch' model, where it tries to find a common ancestor, and apply the appropriate patches to this ancestor, allowing the patch program to try and deal with the differences. Darcs, instead, has the ability to mutate the patches themselves to be applicable in different contexts. It has the advantage of being completely deterministic as far as conflict resolution. It also has the problem that in some instances, it just gives up, declaring that a patch cannot be applied, rather than trying to do so and letting and edit of the conflict take place. The implementors Arch and Darcs seem to understand the complexity and difficulty of cross branch merging, and embrace it head on. Other solutions tend to brush off the problem as not important, and generally leave the user with some very tricky merge cases. Perforce (commercial) attempts to track merge history, but does a terrible job of it. Aegis does seem to track merges well, although it can be obscure figuring out what commands are needed to apply the merges. I've also had problems where it applied the merge correctly, and them completely undid the change when 'resolving' the conflicts. Dave