[darcs-users] Learning about slurpy

David Roundy droundy at abridgegame.org
Sun Nov 16 18:15:25 UTC 2003

On Sun, Nov 16, 2003 at 09:56:31AM -0800, Kevin Smith wrote:
> Greetings all,
> I'm trying to completely understand the darcs code for 'add', and I 
> think I almost have it. But I want to confirm my understanding of a slurpy.
> I am not comfortable thinking the way a lazy functional language thinks, 
> so I'm trying to come up with a non-haskell description of a slurpy.
> My impression is that a slurpy is essentially a sandbox. It starts out 
> as an exact copy of an existing directory structure on disk. You can 
> make changes to it (add, modify, rename, remove) that will seem real 
> when viewed through the slurpy, but which do not affect the underlying 
> directory that it was slurped from.

Yeah, that's basically it.  The only fancy "haskell" thing about a Slurpy
is that I use lazy IO to read everything in (via unsafeInterleaveIO), so
you don't need to actually read a file until you need its contents.

Conversely, this can cause trouble if you modify files after creating the
slurpy, since the modifications may or may not be included in the slurpy.
This is why unsafeInterleaveIO is unsafe: the slurpy can get into a mixture
of old and new versions of files in quite a confusing manner.  So a slurpy
should only be used as long as either the contents are guaranteed to be
unmodified, or you don't care what version you use.

So if someone modifies a local copy of a file during a record, they record
either the new or old version, and that is just the way it is.  If someone
modifies the contents of _darcs/current during a write, they are corrupting
the repo themselves, so they deserve what they get (which is a corrupt

Since a Slurpy reads each file only once (and then stores it in memory),
often it is useful to throw the old one away and slurp a new copy in order
to save memory, which may not be entirely intuitive.

> Hopefully I have this right. It took me quite a while to grasp, partly 
> because of the 'slurp_current' naming problem that is already identified 
> in the code as a FIXME. I would suggest a simple rename to 'slurp_pending'.

Hmmmm.  I've thought about that name, and never went with it because I
think of "pending" as being the changes that are pending.  On the other
hand, since one never slurps changes, I guess it's unambiguous.  Since that
FIXME has been there an awful long time, I think I'll just go with your
David Roundy

More information about the darcs-users mailing list