Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[OSR] Ports-like package management system
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-01-30 (14:07)
From: Nicolas Pouillard <nicolas.pouillard@g...>
Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system
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

> > 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.


Nicolas Pouillard aka Ertai