[darcs-devel] faster darcs whatsnew

David Roundy droundy at darcs.net
Thu Dec 20 12:20:08 UTC 2007

On Thu, Dec 20, 2007 at 12:01:51PM +0000, Simon Marlow wrote:
> David Roundy wrote:
> >On Dec 18, 2007 4:58 AM, Simon Marlow <simonmarhaskell at gmail.com> wrote:
> >>Hmm, this worries me a bit.  I typically have many GHC trees, and I
> >>anticipate using a cache with darcs 2, so will this mean that whatsnew
> >>will sometimes miss changes?  Or will it just be slower?
> >
> >Well, using the file-modification-times optimization always means that
> >whatsnew will sometimes miss changes, since it's always possible that
> >the pristine cache will have the same timestamp as the working directory
> >file, but this is unlikely (and no more likely when interacting with
> >multiple repositories, it's actually in a single repository that you're
> >more likely to modify a file in the working directory within a second of
> >when a darcs record is performed).  The main issue would be that it'd be
> >slower.  This shouldn't be a big issue, since whichever darcs repository
> >you last recorded in (or pulled into, etc) will have a fast whatsnew.
> >
> >One other possibility would be that we could disable global caching of
> >the pristine cache (bad confusion of the term "cache" here).
> Ok.  Though it seems the right thing to do is to store the modification 
> times in a file under _darcs, the file just needs to contain a list of 
> (<file>,<time>) pairs that you read into a Data.Map (you're really just 
> using the filesystem as a Data.Map at the moment).  The question is how 
> much hacking you'd have to do to make this fast enough... I don't know.  It 
> shouldn't be too hard to beat stat() with Data.Map, but there's the 
> overhead of populating the Data.Map in the first place.

I mostly just don't like introducing yet more files under _darcs.  Each
file introduced involves creating a new file format that must be supported
forever, and the less often we do this, the less often we make mistakes!

> I guess this isn't a high priority now.  But it would be good if it were 
> possible to disable globally caching the pristine copy, so we can get the 
> darcs1 behaviour.  Perhaps have separate 'cache:' and 'cachepristine:'?

I agree.  Or maybe cache: and cachepatches: (the latter not caching
David Roundy
Department of Physics
Oregon State University

More information about the darcs-devel mailing list