[darcs-users] case insensitivity and inconsistent state

[Eric Kow]

On Wed, May 13, 2009 at 08:51:39 +0100, Simon Peyton-Jones wrote:
>         (A) any darcs command may arbitrarily screw up your working
>         files

...

> I may have an entire day's work in my working files, or much more.  If
> you are really saying (A) then I'll have to cp -r before every darcs
> command.  Please don't say (A).
 
I regret that I am saying what I hope to be a sufficiently small and
well-defined version of (A) that one can live with.  In other words

>         any darcs command
The darcs pull and apply commands
>         may arbitrarily screw up
may screw up by attempting to merge in patches that are meant for
two different files within the same working file
>         your working files
specifically the working files whose filenames differ only in case...

which as you and Tristan's repository show can happen just by pulling
in patches from two separate places without the user having to force
their creation :-(

To be clear, I consider this to be a bug, one that can best be fixed by
long term work such as that proposed by Ganesh.  It is likely that this
will be something we do for darcs 3. I plan on submitting my test case
to our bugs directory.

[As a side note, I wonder how well the other revision control systems
cope with this kind of thing...]

> You may say
> 
>         Record a patch first, so that your working files contain
>         no useful data

This is a useful practice.  Now it so happens that we had a feature
request that would do this for you, but I think we must have decided
that wasn't so useful now that darcs backs up your working files
whenever it detects a conflict, or whenever it is about to clobber
one of them by renaming something onto it.  (This is what this
-darcs-backup-0 business is about by the way).
 
> But that fails, because the patch may conflict with the pulled
> patches, and that leads to a different darcs bug, so I have learned
> NEVER to have conflicts.  No.  In fact, I *unrecord* my local patches,
> pull, and the re-record.  So my working files may have a *lot* of work
> in them.

I'm a bit surprised that unrecording local patches before you pull them
avoids darcs getting stuck in an exponential blow-up.  Have you verified
this in practice?  If it does work then you should still be able to get
the same effect by unrecording and then re-recording a single draft
patch.  The reason why I would be surprised if you told me that this
actually does work is because darcs sees patches everywhere, whether you
record them or not.  So whatever conflicted-related issues affect
recorded patches should affect *un*recorded patches equally.  The only
plausible explanation I have on hand for why something like this might
work is that it may have something to do with how conflicts nest, but
then another darcs hacker would have to step in and explain this to me.

So my request for now is to request that you get back to recording your
working directory changes perhaps in a DRAFT patch which you could
unrecord after the fact... and yell at us the next time this causes you
a headache.  Does anybody else following this discussion care to comment
on my recommendation?

> Enough from me. I'm just playing Joe User here. I know that it's hard
> to satisfy users, from the other end.  But it's good to know what they
> think.

Absolutely. Thanks for taking the time out to do this; your comments are
the inspiration behind many of our improvements to darcs (such as the
automatic backup mechanism, and the apply --dry-run feature).
Thank-you!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090515/eaea4ed2/attachment.pgp>