[darcs-users] darcs patch: Add forceHashSlurped that hashes the slu... (and 1 more)

David Roundy daveroundy at gmail.com
Mon Sep 1 14:26:49 UTC 2008


On Sun, Aug 31, 2008 at 9:17 AM, Petr Rockai <me at mornfall.net> wrote:
> slurpHashed will take a "hashed" directory and produce an appropriate
> SlurpDirectory (files coming from drive in it will have the "Maybe String"
> field in them set to Just <hash>)
>
> hashSlurped will take a SlurpDirectory (possibly modified through the
> WriteableDirectory interface to SlurpMonad -- files produced this way will have
> the Maybe String field set to Nothing) and write out any files, that have their
> "Maybe String" set to Nothing.
>
> This means, that hashSlurped is appropriate in these two scenarios:
> - SlurpDirectory has been obtained from a non-hashed slurping action
> - SlurpDirectory has been obtained from slurpHashed and the directory parameter
>  to hashSlurped matches that passed to slurpHashed
>
> However, the repair code as it is introduces a situation, where hashSlurped is
> not appropriate:
>
> - SlurpDirectory has been obtained from slurpHashed, but hashSlurped is being
>  called on a different directory -- we basically want to copy the hashed
>  subdirectory to a new location
>
> This is where forceHashSlurped comes into play, as it implements the last
> scenario, without changing behaviour of hashSlurped. It could probably get a
> better name, but so could hashSlurped -- although maybe a wider refactor would
> be in place, to enforce that hashSlurped can't be used in the 3rd problematic
> case described above.
>
> Hopefully, this time the explanation is clear enough and we can move on --
> either renaming the functions or doing something else, but actually moving
> towards fixing issue971...

It sounds to me like this is a bug in hashSlurped that should be
fixed.  hashSlurped should always work right, which shouldn't be too
hard.  We just have to check that the hash files referred to in Just
<hash> are present in the subdirectory of _darcs/ that we're writing
to.  It's a quick check (just a doesFileExist) in the common case
where it's already present, and it should be able to ensure that this
kind of bug won't happen.

David


More information about the darcs-users mailing list