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

[Petr Rockai]

"David Roundy" <daveroundy at gmail.com> writes:
> Another alternative would be to simply always keep hash files that
> refer to file or directory content in a fixed directory.  The latter
> option wouldn't be a bad idea at all, as it would also promote sharing
> of disk space.  In fact, that would be my leaning at the moment.  If
> we keep all HashedIO files in "pristine.hashed", then the whole
> problem can't occur, and I don't see any downside.  Well, I guess
> there's the downside that cleaning the pristine.hashed directory could
> be more complicated, as we wouldn't know how many other files might be
> stashed away there.  But we only cleanRepository in optimize, and
> optimize doesn't need to be either amazingly fast or amazingly simple.
I have been thinking about that approach before, but have discarded it on the
paranoia argument. It still might be worthwhile: the downside is, that repair
would pollute the pristine.hashed with a very large number of stale files:
basically, any intermediate repository states that we write out, which aren't
that few. So we really want to call clean_hashed every now and then while
running repair (I think ext3 might have issues with very large directories,
too, and also for space reasons...).

>  One major advantage of this approach is that it decreases the number
> of arguments to these functions, which should make them simpler and
> safer to use.
True, and it doesn't actually matter too much to have newpristine at all, and
while we don't update the root pointer in hashed_inventory, we should be all
safe. (We might need to extend clean_hashdir to take a list of root hashes
instead of a single hash, thinking of that.)

>> However, there is another issue with that approach. If we encounter hash
>> failures in pristine, we might want repair to fix those -- which it will under
>> forceHashSlurped as proposed, but won't under hashSlurped with a doesFileExist
>> call in it.
>
> I don't think this is a problem.
(Well, I have had experience of seeing some hash failures in http://darcs.net
recently, although I haven't investigated too much, as I had some repository
corruption issues before, so I have been so far assuming it's debris from that
incident. It might still be worthwhile to have ability to repair such
corruption if it happens. Probably rm-ing any such files at start of repair
would be enough.)

Yours,
   Petr.

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation