[darcs-devel] Re: [issue434] Darcs grief: Issue 274

[Benjamin Franksen,15.8.202,6392-4982,]

org wrote:
> Quoting David Roundy <droundy at darcs.net>:
>> On Tue, Apr 17, 2007 at 10:21:02PM -0700, Kevin Quick wrote:
>> > I am a bit concerned that it was a darcs pull that encountered this
>> > problem for you.  In my case, it was a push from a user that didn't
>> > have proper access rights to some of the files in my repo (and did on
>> > others).  I wouldn't have expected this in the pull case, however.
>> > Are you certain it was a pull, and in either case, have you been
>> > able to reproduce it?
>> 
>> It's a windows-specific case, which I believe we understand.  You can't
>> delete an open file on windows, and darcs always modifies files by
>> writing
>> a new copy and then replacing the old with the new.  But Simon is
>> executing a script in the working directory that darcs wants to modify,
>> and therefore
>> it can't, which causes the whole trouble.  It wouldn't happen with POSIX
>> file system semantics, which is why it hasn't bothered people before.  :(
> 
> Ah, OK.  Different root problem, but same results though: the patches are
> not applied but the working directory is modified.
> 
> I'm thinking there are two elements here:
>   1) Fix (if appropriate/possible) the root cause of both issues (Simon's
>      above and mine with the pusher privilege problems).
>   2) In the event that any pull/push/apply fails due to this type of
>      unexpected issue, it should return the entire current tree to its
>      original form (as much as possible).  This might be done by doing
>      all modifications on a copy and then swapping in that copy (expensive
>      spacewise) or reverting all operations (similar to applying the
>      inverse patch to the working tree, but not entirely).

The 'same' problem happens with Linux when you have a patch that removes a
directory, and in your working there are (unrecorded) subdirectories of
that directory. Then darcs pull will fail to remove the directory and won't
apply any further patches to the working directory. Since our build system
creates subdirectories during the make run this is quite likely to happen
and has already caused a lot of grief. The 'unrecord trick' mentioned by
Grant Husbands works here, too, but it remains a problem and could be
avoided. For instance, darcs could create a dummy patch containing all
unrecorded changes (everything listed by darcs whatsnew -l), try to apply
the patches, revert all local changes (thus repairing the working directory
in case of a failure), and then unrecord the dummy patch.

Cheers
Ben