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 optimisation? > - 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 change? > 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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
