These are Simon Marlow's notes on areas that darcs needs to improve on to be
useful for GHC:

I promised to put together our reasoning on why we don't think moving to
darcs2 would help enough.  Here's a summary:

 - using the darcs2 format may well fix the exponential-time merge problem,
  but the UI for merging conflicts is still lacking in many important ways
  in darcs:

  * The conflict markers are not annotated with the patch that they came
    from, and the ordering of patches in conflict markers is
    non-deterministic (when I asked about this problem, I was told it was
    hard to fix).

  * The 'darcs changes' output only shows one of the patches that is
    conflicting, you have to guess at the other one(s).  Also, it doesn't
    show which patches are conflict resolutions.

 - Performance.  darcs2 regressed in performance for many operations we
  commonly use.  I've submitted some measurements for some things, but
  it's pretty easy to find your own test cases: things like "darcs add",
  "darcs whatsnew", "darcs unrecord" are all slower than darcs 1.  When
  simple operations take multiple seconds to complete, it really slows
  down your workflow.

 - I still can't use 'darcs annotate' because it's too slow.  Also, we
  can't browse the GHC repository on the web because the web interface
  wants to do 'darcs changes <file>', and that takes minutes.  It's
  possible with caching, but you still have to regenerate the cache
  after a change.

 - why can I do a complete git clone of a remote GHC repo in a few minutes,
  but it takes hours to do a complete 'darcs get'?

 - Bugs.  Many bugs have been fixed in darcs2, which is great, but we
  did already encounter one (hard to reproduce) bug on Windows,
  when trying to get an up-to-date repo.  Perhaps bugs will be less of
  an issue in the future, but we have had painful experiences
  particularly on Windows and I know the darcs developers are still
  not actively testing on Windows.

Attachments

• unnamed

It's good that these concerns are documented, but what is the purpose of having
in the bug tracker? Is it considered a "bug" that darcs doesn't meet all of the
concerns of the GHC project?  

My hope is simply to have some stated measure so we can determine when this bug
tracker entry is considered resolved.

On Mon, Aug 11, 2008 at 6:53 PM, Mark Stosberg <bugs@darcs.net> wrote:

>
> Mark Stosberg <mark@summersault.com> added the comment:
>
> It's good that these concerns are documented, but what is the purpose of
> having
> in the bug tracker? Is it considered a "bug" that darcs doesn't meet all of
> the
> concerns of the GHC project?
>
> My hope is simply to have some stated measure so we can determine when this
> bug
> tracker entry is considered resolved.

Your concerns are valid.  I saw the feedback in an email SimonM sent and
hastily saved it somewhere.  This was the first place I thought of.  Others
have commented that this should probably get moved to the wiki.

Jason

Attachments

• unnamed

Eric,

I see you marked this as "release critical for 2.1", but when is this issue
'resolved'? It seems rather broad to work on directly. 

I would rather see this as several specific tickets, such as one for conflict
markers and one for 'darcs changes' conflict output, etc.

You're right.  Let's track down the issues that are related to these concerns
and create the new tickets necessary.  I guess the group ticket should be on the
wiki, as people and Jason point out.

  * The conflict markers are not annotated with the patch that they came
    from, and the ordering of patches in conflict markers is
    non-deterministic (when I asked about this problem, I was told it was
    hard to fix).

That's issue833

  * The 'darcs changes' output only shows one of the patches that is
    conflicting, you have to guess at the other one(s).  Also, it doesn't
    show which patches are conflict resolutions.

I think this needs a ticket, no?

 - Performance.  darcs2 regressed in performance for many operations we
  commonly use.  I've submitted some measurements for some things, but
  it's pretty easy to find your own test cases: things like "darcs add",
  "darcs whatsnew", "darcs unrecord" are all slower than darcs 1.  When
  simple operations take multiple seconds to complete, it really slows
  down your workflow.

One of these is issue973.

 - I still can't use 'darcs annotate' because it's too slow.  Also, we
  can't browse the GHC repository on the web because the web interface
  wants to do 'darcs changes <file>', and that takes minutes.  It's
  possible with caching, but you still have to regenerate the cache
  after a change.

That's issue984

 - why can I do a complete git clone of a remote GHC repo in a few minutes,
  but it takes hours to do a complete 'darcs get'?

That's issue987

 - Bugs.  Many bugs have been fixed in darcs2, which is great, but we
  did already encounter one (hard to reproduce) bug on Windows,
  when trying to get an up-to-date repo.  Perhaps bugs will be less of
  an issue in the future, but we have had painful experiences
  particularly on Windows and I know the darcs developers are still
  not actively testing on Windows.

We should work with Simon M to get more details on these bugs...

We're making some progress here:
- whatsnew too slow on hashed repositories fixed by upgrading to GHC 6.8.3
(issue973)
- annotate too slow, will perhaps improved by Benedikt's filecache work in darcs
2.2? (issue984)

On the other hand
- fetch files over HTTP being slow (issue987)... I'm not sure we can do very
much for this by January.  We may have to postpone this until 2009-07
- improved conflicts marking (issue883) is unlikely to arrive very soon

Therefore, I am removing the ReleaseGoal topic from this ticket (because it's
not realistic).  I am also marking this ticket a duplicate because we already
have farmed everything out into sub-tickets.  Thanks!