[darcs-users] no more checkpoints, but hashed repos for GHC in Darcs 2.4?

Eric Kow kowey at darcs.net
Mon Sep 14 11:31:04 UTC 2009

On Mon, Sep 14, 2009 at 09:43:24 +0100, Simon Marlow wrote:
> This is fine by me.  But we need to work with you folks to make sure
> that hashed repos are not a regression for us before we're forced to
> switch.

Good.  I realise I've been waving the poms-poms around a lot, so I want
to make sure this one big of cheerleading comes out the clearest.
Megaphone time.  I think this should be our number one goal for January:

  Darcs 2.4 should handle hashed repositories so well that the
  GHC team will switch over to using them.

Now, this is the Darcs project we're talking about here, so this doesn't
mean that hurry, cut corners, or try to merge darcs-hs in at any cost.
What it does mean is that we give ourselves a sense of mission, that
hashed-storage be on our minds until the job is done. (Rah, rah Darcs!)

I've somewhat brutally updated the roadmap and bug-tracker to narrow our
focus.  Everything that was previously targeted for Darcs 2.4 has been
shifted up a release.  Hashed-storage remains.  We must get this one
right (Rah?).  I'm also hoping that we can have a purely Darcs hacking
sprint sometime on a non-Thanksgiving weekend of November in Amsterdam
and Portland, conditions permitting.  More on that later!

> That means fixing at least
>   - http://bugs.darcs.net/issue1582 (permission denied on Windows,
>     perhaps already fixed in hashed-storage, I need to check)

Just to add to that: this appears to be fixed in hashed-storage 0.3.7
if I understand Petr correctly. (Rah!)

>   - http://bugs.darcs.net/issue1589 (7-second overhead for pulling
>     or unpulling one patch)

This one still needs attention.

We've pretty much verified that this is slow with hashed repositories
and fast with old-fashioned repositories.  OK one second comes from the
deliberate delay and maybe the extra 6 comes from needless inventory

>   - timestamps getting out of sync by hard-linking the hashed pristine files.
>     I presume this is fixed by darcs-hs anyway.

I believe that for projects with branches, fixing this is where the
biggest positive impact from hashed-storage will be (Rah!).

>   - dividing the cache into subdirectories to avoid bad filesystem
>     performance with large directories.

That's http://bugs.darcs.net/issue1536 :-)

Petr: how do you feel about this?  Do you rate this as being easier
than packs?  Is it realistic to want this in Darcs 2.4?  I am also
concerned about backward compatibility.  How do we handle this?  Format

> Right now I'm using darcs 2.2 with darcs-1 repos at work, and I'm
> pretty happy with it.  On my laptop I'm using darcs 2.3 with hashed
> repos, and while some things are blindingly fast (whatsnew), some
> other things are grotesquely slow :-(

Don't forget the darcs revert workaround in the interim.

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090914/eeeaa527/attachment.pgp>

More information about the darcs-users mailing list