[darcs-devel] Filesystem in DB, but data in filesystem

Tommy Pettersson ptp at lysator.liu.se
Mon Jul 30 13:06:05 PDT 2007


On Mon, Jul 30, 2007 at 02:52:59PM +0200, Salvatore Insalaco wrote:
> This is maybe not as bulletproof as the checksum solution, but it
> could work, and it is O(1) on file length.

I suspect we don't really need a full hash. But the reason we
check the file is we're going to do a diff on it, so the whole
operation is already O(filelength) anyway.

> We lose the "case-sensitivity-on-case-insensitive-fs" property, but
> again we gain in simplicity and probably performance (I wouldn't bet
> on this one).

I think the case-sensitivity would be a really good thing. It
would mean a case-insensitive user would notice from the diff at
recording time (if not sooner) something was fishy. And she
could then do 'darcs mv Foo foo2; darcs revert', and record the
changes to foo2 but NOT the move, and send / push them to a
case-sensitive repo without a trace of case-insensitivity.

> Anyway, I think we are getting nearer to a good solution to this
> problem. A few more "idea-patches" and I'll be ready to start the
> implementation :).

Yes. The light-weight idea of just adding an index file with
timestamps would probably take care of detecting most pristine
corruption with very low overhead. To fix the problem with
case-insensitivity would of course be a step better. I also
think getting away from a copy of the working file tree, and
have a single file or a flat file structure with scary looking
file names could help, because we don't have many reports of
programs recursing into _darcs/patches/ modifying
20070727001358-72aca-d1550c794a9048f06fcc57162f44436ea0ba027e.gz;
it is probably too easy to accidently modify a file in pristine
without noticing it is the pristine cache.


-- 
Tommy Pettersson <ptp at lysator.liu.se>


More information about the darcs-devel mailing list