caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Nicolas Pouillard" <nicolas.pouillard@gmail.com>
To: jon <jon@ffconsultancy.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system
Date: Wed, 30 Jan 2008 15:06:38 +0100	[thread overview]
Message-ID: <1201700234-sup-7930@ausone.inria.fr> (raw)
In-Reply-To: <200801301325.29265.jon@ffconsultancy.com>

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

Excerpts from jon's message of Wed Jan 30 14:25:28 +0100 2008:
> On Wednesday 30 January 2008 12:00:01 Nicolas Pouillard wrote:
> > Users  that  consider  darcs  broken and/or unusable are not darcs users,
> > they perhaps  tried  it, that's all.
> 
> So you have not personally experienced performance problems with darcs.

For day-to-day operations... no.

* darcs get URL:
  The  initial "darcs get" can takes some time, because like any other DVCS
  it has to checkout all versions of the project.

  However  having  multiple  branches  of the same project don't imply running
  more  than  one  "darcs  get"  of the upstream URL. One rather clone our our
  local  copy  to  make  another branch. Hard links are used in order to share
  common patches.

  Moreover  darcs  supports  partial  checkout  up  to a checkpoint. Basically
  upstream  makes  checkpoints  when regularly tagging the upstream repo. Then
  if  you  do  a  partial  get,  you only take the last checkpoint and patches
  after  this checkpoint. The problem with partial repository is when you want
  to  access  the  history  before  the  checkpoint,  in  darcs1 you can't. In
  darcs2, it will lazily download missing patches when needed.

  Then  darcs2  have  made  a  lot of progress for improving "darcs get", like
  http pipelining.

* When having a lot of conflicts:
  darcs1  suffer  from  a flawed conflict-resolution algorithm (an exponential
  one). darcs2 handle much better this kind of situations.

* There   is some other cases where darcs can be very slow. However that's not
  when  doing  day-to-day  tasks  but  when  using advanced repository hacking
  things.

> > IMHO  they've  applied  the  "correction  before  optimization"  principle.
> > A principle that we often spread in functional programming community.
> 
> If darcs is unusably slow then its theoretical correctness is irrelevant. 

But  that's  not the case. I use it all the day long and I'm far from being alone
in this case.

> Regardless, its actual correctness is still in question because it has so few 
> users that it is basically untested software.

I  really  doubt  that.  There is an incomplete and certainly outdated list of
projects  using  it  [1].  I also that darcs is far more mature than git or hg
(original announcement in 2003).

Moreover  as  you  know, some programming techniques and languages can help to
gain robustness without huge mass user testing.

[1]: http://wiki.darcs.net/DarcsWiki/ProjectsUsingDarcs

-- 
Nicolas Pouillard aka Ertai

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

  reply	other threads:[~2008-01-30 14:07 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
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 [this message]
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=1201700234-sup-7930@ausone.inria.fr \
    --to=nicolas.pouillard@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=jon@ffconsultancy.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).