[darcs-users] Re: darcs and patches@ mail

David Roundy droundy at abridgegame.org
Sat Feb 21 15:38:35 UTC 2004


On Sat, Feb 21, 2004 at 09:44:50AM -0500, Kevin Smith wrote:
> David Roundy wrote:
> >Switching to using a database to store current is definitely appealing,
> >but certainly not for until after 1.0.
> 
> If you even consider this, please make it optional. I have a very strong 
> preference for plain files over binary database blobs. I will sacrifice 
> disk space. I will sacrifice speed. The simplicity, clarity, and 
> recoverability of plain files are all worth it to me.

Yes, this would be optional.  The implementation I'm envisioning is
extending "slurp" and friends to be able to read and write from a database
containing filenames and contents as well as an actual directory.  Thus the
changes needed to use a database could *mostly* be isolated in
SlurpDirectory.lhs.  This nice way of coding it would also mean that you
could (almost?) transparently use either a directory or a file as
_darcs/current.

An example of a side-benefit (besides the main benefit of atomic writes) of
using a database is that besides using file modification times to see if a
file is changed, we could also store inode numbers, which reduce just a tad
the danger of users modifying their file within a second of recording a
change to that file and then having darcs not notice that the file was
modified.

And even if you don't store _darcs/current as a database, creating the
temporaries used in darcs check as databases may speed things up, possibly
dramatically, especially in large repos (where the limiting factor is
currently mostly directory reads and fstat calls).  Since running darcs
check on the linux kernel repository takes my machine about 22 hours, I'd
say that speed here could be a pretty important factor...
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list