From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 259F9BC6C for ; Tue, 29 Jan 2008 18:35:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANPynkfAXQImh2dsb2JhbACQHgEBAQgKKYEUnVY X-IronPort-AV: E=Sophos;i="4.25,270,1199660400"; d="scan'208";a="7392795" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 29 Jan 2008 18:35:10 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0THZ5ia017035 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 29 Jan 2008 18:35:10 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABvynkfBL1AZh2dsb2JhbACQHgEBAQgEBimBFJ1W X-IronPort-AV: E=Sophos;i="4.25,270,1199660400"; d="scan'208";a="21945238" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Jan 2008 18:35:10 +0100 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.0/8.14.0) with ESMTP id m0THZ8Sq015396; Tue, 29 Jan 2008 18:35:08 +0100 Message-ID: <479F63CC.60004@exalead.com> Date: Tue, 29 Jan 2008 18:35:08 +0100 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: yminsky@gmail.com, Caml-list List Subject: Re: [Caml-list] [OSR] Ports-like package management system References: <479F0664.2070706@exalead.com> <891bd3390801290511q29ab5fd4y78ee6d8614461487@mail.gmail.com> In-Reply-To: <891bd3390801290511q29ab5fd4y78ee6d8614461487@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 479F63C9.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 yaron:01 minsky:01 ocaml:01 haskell:01 violate:01 haskell:01 merging:01 renames:01 intensively:01 ocaml:01 cygwin:01 Yaron Minsky a écrit : > On Jan 29, 2008 5:56 AM, Berke Durak > wrote: > > Basing a PMS for Ocaml on a VCS written in Haskell would violate the > ``Trading with the Enemy'' act. Moreover Darcs has some performance > problems of its own. > > > Come now, Haskell is a dear friend and relative, not an enemy at all. No but seriously, what would we look like if the semi-official distribution depends on Haskell? > Besides, darcs has some key advantages for this kind of use. > Cherry-picking and flexible maintenance of patches on top of someone > else's tree would be very valuable for this kind of application, and > neither hg nor git support that use case well. And I believe the darcs > team is making real advances towards fixing these problems. I'll rank required VCS features : * Distributed nature (for easy collaboration) * Portability (Windows) * Speed (for fast checkouts) * Reliability * User community * Ease of use (not a big concern since the VCS commands would be called by the distribution management code anyway) * Advanced merging features > If not darcs, I would choose hg next. hg supports windows well, which > is a big deal, I think. Its user interface was more pleasant than git's > last I checked. And it has some support for renames (not as good as > darc's or bzr's, but still good.) We've used hg very intensively at > Jane Street and have been very happy with the results. I've been using hg daily for about a year now and I am quite pleased with it. My only reservation is that it is written in Python... However, I did a sloccount on Git today and I got: ansic: 70503 (48.98%) sh: 36153 (25.12%) perl: 17731 (12.32%) tcl: 14805 (10.29%) python: 2839 (1.97%) lisp: 1682 (1.17%) asm: 220 (0.15%) whereas the same on hg gives: python: 14610 (95.29%) ansic: 722 (4.71%) Mercurial is obviously cleaner and more portable. It runs well under Windows and has only three small files written in .c ; git is an unholy mixture of mostly C and shell (the Perl is in the plugins) and it has a bad reputation under Windows (not very surprising...). However Darcs really has some show-stopping performance problems. Proponents of Darcs can say that it'll get really better with Darcs 2.0 or whatever but, in practice, full repository checkouts over the network are unacceptably slow, and this is probably the most important thing for the application we are envisioning: a ports-like system. I checked out Darcs itself and it took 15 minutes; while checking out Git or Mercurial took only one or two minutes. The slowness of Darcs is well-known, many people are talking about it. It seems that the latest repository format doesn't help much: http://lists.osuosl.org/pipermail/darcs-devel/2008-January/007057.html So I'm leaning towards Hg (and my Aurochs & Jsure repositories are already under Hg), but could agree on Git. Also note that Git stores files as snapshots and not as a sequence of patches. Git also has some nifty advanced features: http://blog.moertel.com/articles/2007/12/10/how-i-stopped-missing-darcs-and-started-loving-git Both Mercurial and Git are used by first-class open-source projects (the kernel, Mozilla ...). Darcs has only GHC and Darcs (duh!). Also Mercurial has been selected over Git by Sun for OpenSolaris: http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html Darcs may be based on some abstract ideas having some sex-appeal to theoretical computer scientists, and Git may have some sex-appeal to C hackers. But... * In practice, Darcs, as is currently distributed, is really slow * Darcs is written in Haskell which will give Haskellers ammunition in flame wars^W^W^W^W^W might be bad for Ocaml evangelism. * Apparently Darcs had serious fundamental algorithmic problems due to exponential blowup with commuting patches, and some practical problems with repository corruption under concurrent access... * Git is written mostly in C with lots of shell scripts, which doesn't seem very appropriate for such an application in 2008; it has portability problems under Windows and seems to require Cygwin. * The advanced features of Darcs & Git (cherry-picking, bisection, stash...) may be all fine and dandy but we don't need them for Ports. Heck, we could almost use Subversion... Hence I agree with Yaron and recommend Mercurial. > It would also be nice to have a set of versions of the various libraries > that hang together, as GODI does. Otherwise, problems in the case where > there are packages A, B and C where A depends on B and C and B depends > on C. You need a version of C that works with your versions of A and B, > or you're sunk. So some central repo where you can maintain a set of > "safe" versions would allow for a developer to ask for a easily pull a > collection of working libraries. I recommend the use of a VCS precisely for that kind of thing: to be able to depend on an exact revision. -- Berke DURAK