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 0EBB7BB81 for ; Tue, 21 Dec 2004 23:36:33 +0100 (CET) Received: from smtp.syd.swiftdsl.com.au (smtp.syd.swiftdsl.com.au [218.214.224.138]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id iBLMaUID012639 for ; Tue, 21 Dec 2004 23:36:31 +0100 Received: (qmail 27926 invoked from network); 21 Dec 2004 22:36:31 -0000 Received: from unknown (HELO coltrane.mega-nerd.net) (218.214.64.136) by smtp.syd.swiftdsl.com.au with SMTP; 21 Dec 2004 22:36:31 -0000 Received: from coltrane (localhost [127.0.0.1]) by coltrane.mega-nerd.net (Postfix) with SMTP id B04877AD7 for ; Wed, 22 Dec 2004 09:36:27 +1100 (EST) Date: Wed, 22 Dec 2004 09:36:27 +1100 From: Erik de Castro Lopo To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] [OT] Rant about VCS: Conclusions Message-Id: <20041222093627.5a5376a3.ocaml-erikd@mega-nerd.com> In-Reply-To: <41C89DB2.4020105@orcaware.com> References: <41C3126A.3060101@barettadeit.com> <20041217213753.GA2295@pegasos> <20041218092716.18ca0ed7.ocaml-erikd@mega-nerd.com> <41C7E7EE.6030709@barettadeit.com> <41C89DB2.4020105@orcaware.com> Organization: Erik Conspiracy Secret Labs X-Mailer: Sylpheed version 1.0.0beta3 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41C8A56E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 zajac:01 orcaware:01 wrote:01 merging:01 cvs:01 merging:01 conflicts:01 nospam:98 tree:02 otoh:02 productivity:03 blair:03 blair:03 dec:03 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 Tue, 21 Dec 2004 14:03:30 -0800 Blair Zajac wrote: > Regarding merging, unlike CVS, Subversion has changesets, so merging is > simply picking the changeset(s) you want from one path and applying it > to another: Ahh, now I remember the problem subversion has with merging across branches with respect to Arch. Please correct me if I am wrong, but from what I have heard, subversion is not able to recognise if a changeset has already been applied or not and trying to apply a changeset which has already been applied can lead to merge conflicts which need manual intervention to correct. 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. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ I have found that good programmers either do not make the kind of mistakes that Ada can prevent, or insert enough checks that they catch those mistakes about as efficiently as an Ada environment can. At that point, the use of Ada gives no further productivity advantage.