caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Berke Durak <berke.durak@exalead.com>
To: yminsky@gmail.com, Caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Ports-like package management system
Date: Tue, 29 Jan 2008 18:35:08 +0100	[thread overview]
Message-ID: <479F63CC.60004@exalead.com> (raw)
In-Reply-To: <891bd3390801290511q29ab5fd4y78ee6d8614461487@mail.gmail.com>

Yaron Minsky a écrit :
> On Jan 29, 2008 5:56 AM, Berke Durak <berke.durak@exalead.com 
> <mailto:berke.durak@exalead.com>> 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


  parent reply	other threads:[~2008-01-29 17:35 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29 10:56 Berke Durak
2008-01-29 11:12 ` [Caml-list] " David Teller
2008-01-29 13:11 ` Yaron Minsky
2008-01-29 14:04   ` Nicolas Pouillard
2008-01-29 17:35   ` Berke Durak [this message]
2008-01-29 18:02     ` Bünzli Daniel
2008-01-29 18:10     ` Paul Pelzl
2008-01-29 22:26     ` Paolo Donadeo
2008-01-30  1:55       ` Bünzli Daniel
2008-01-29 22:46     ` Paolo Donadeo
2008-01-29 13:47 ` Yaron Minsky
2008-01-29 14:04   ` Nicolas Pouillard
2008-01-29 16:00 ` Alain Frisch
2008-01-30  6:58   ` Yaron Minsky
2008-01-30  8:56     ` Nicolas Pouillard
2008-01-29 17:56 ` Bünzli Daniel
2008-01-29 18:17   ` Nicolas Pouillard
2008-01-29 19:13     ` Bünzli Daniel
2008-01-30  8:49       ` Nicolas Pouillard
2008-01-30 11:15         ` Bünzli Daniel
2008-01-30 11:52           ` Nicolas Pouillard
2008-01-29 18:47 ` Hezekiah M. Carty
2008-01-30  9:06 ` Sylvain Le Gall
2008-01-30  9:39   ` [Caml-list] " Berke Durak
2008-01-30  9:53     ` Sylvain Le Gall
2008-01-30 10:50       ` [Caml-list] " Nicolas Pouillard
2008-01-30 11:15         ` Bünzli Daniel
2008-01-30 11:54           ` Nicolas Pouillard
2008-01-30 13:58             ` Sylvain Le Gall
2008-01-30 14:08               ` [Caml-list] " Nicolas Pouillard
2008-01-30 11:15       ` Berke Durak
2008-01-30 11:47         ` Bünzli Daniel
2008-01-30 13:55           ` Sylvain Le Gall
2008-01-30 13:54         ` Sylvain Le Gall
2008-01-30 14:24           ` [Caml-list] " Berke Durak
2008-01-30 14:35             ` Sylvain Le Gall
2008-01-30 19:48             ` [Caml-list] " Bünzli Daniel
2008-01-30 18:12           ` Vlad Skvortsov
2008-01-30 16:32       ` Michael Ekstrand
2008-01-30 16:44         ` Sylvain Le Gall
2008-01-30 18:03         ` [Caml-list] " Nicolas Pouillard
2008-01-30 19:45         ` Olivier Andrieu
2008-01-30 19:53           ` Vlad Skvortsov
2008-01-30 10:45     ` Sylvain Le Gall
2008-01-30  9:51   ` [Caml-list] " Jon Harrop
2008-01-30 10:18     ` Sylvain Le Gall
2008-01-30 10:43       ` [Caml-list] " Jon Harrop
2008-01-30 12:00         ` Nicolas Pouillard
2008-01-30 13:25           ` Jon Harrop
2008-01-30 14:06             ` Nicolas Pouillard
2008-01-30 12:37   ` Pietro Abate
2008-01-30 13:26     ` Stefano Zacchiroli
2008-01-30 14:07     ` Gerd Stolpmann
2008-01-30 13:37       ` Stefano Zacchiroli
2008-01-30 15:12         ` Gerd Stolpmann
2008-01-31  9:02           ` Stefano Zacchiroli
2008-02-01 15:03             ` Gerd Stolpmann
2008-02-03 20:21               ` Stefano Zacchiroli
2008-02-04  3:40                 ` Matthew Hannigan
2008-02-04 18:42               ` Nathaniel Gray
2008-01-30 17:42       ` David Allsopp
2008-01-30 14:13     ` Sylvain Le Gall
2008-01-30 20:22       ` [Caml-list] " Bünzli Daniel
2008-02-08 22:24       ` N. Owen Gunden
2008-01-30 15:15     ` Jon Harrop
2008-01-30 12:37 ` [Caml-list] " Berke Durak
2008-02-13  8:45 ` David Teller
2008-02-13 10:02   ` Sylvain Le Gall
2008-02-13 10:48     ` [Caml-list] " Berke Durak
2008-02-13 13:51       ` Sylvain Le Gall
2008-02-13 14:10       ` [Caml-list] " Richard Jones
2008-02-13 14:22         ` Sylvain Le Gall
2008-02-13 17:57           ` [Caml-list] " Richard Jones
2008-02-15  8:13       ` Maxence Guesdon
2008-02-15  9:47         ` Berke Durak
2008-02-15 10:24           ` Maxence Guesdon
2008-02-15 10:59             ` Stefano Zacchiroli
2008-02-15 15:45               ` Maxence Guesdon
2008-02-15 13:35         ` Ralph Douglass
2008-02-15 14:08           ` Christophe TROESTLER
2008-02-13 12:13     ` David Teller
2008-02-13 13:48       ` Sylvain Le Gall
2008-02-13 13:58         ` [Caml-list] " David Teller
2008-02-13 14:20           ` Sylvain Le Gall
2008-02-13 14:28             ` [Caml-list] " David Teller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=479F63CC.60004@exalead.com \
    --to=berke.durak@exalead.com \
    --cc=caml-list@inria.fr \
    --cc=yminsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).