[darcs-users] case insensitivity and inconsistent state

Jason Dagit dagit at codersbase.com
Wed May 13 20:53:52 UTC 2009


Forgive my top posting, but...
I think both of you would benefit from doing dry runs more frequently before
pulling:
http://darcs.net/manual/node8.html#SECTION00862000000000000000

--dry-run

That could give you heads up about conflicts before they pollute your
valuable working copies.

Otherwise, I absolutely agree with your criticisms of the conflict marking.
 I view the current marking as more of a "proof of concept" now it's time to
get in the code and make it industrial strength.  Although, I probably
wouldn't change the order of the conflicts, instead I would try to find a
way to make the origin of the conflicts clear.

Have you ever tried using a diff viewer when you pull?  That may help with
visualizing the conflicts:
darcs pull --external-merge COMMAND

You can set --external-merge in your darcs defaults so you don't have to
type it everytime and the documentation for COMMAND is here:
http://darcs.net/manual/node8.html#SECTION00810030000000000000

Thanks,
Jason

On Wed, May 13, 2009 at 2:42 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 13/05/09 08:51, Simon Peyton-Jones wrote:
>
>  (Actually there's a serious problem with conflict markers, namely that the
>> "old" and "new" slabs are sometimes new/old and sometimes old/new.  But that
>> is a different bug.)
>>
>
> in fact, as I understand it, the conflict markers show you new1/new2 (ie.
> the versions from the two patches that conflicted, in a random order), you
> don't get to see the "old" unless you inspect the patches. I've mentioned
> this before and was told it was "hard to fix".  Still, I think better
> conflict markup would be high up on our darcs wishlist.
>
>  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).  But (B) implies that you must treat working files
>> with the same care that you do the repo itself.
>>
>> You may say
>>
>>         Record a patch first, so that your working files contain
>>         no useful data
>>
>> 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.
>>
>
> Recording before pulling is the right thing - but you're only recording
> temporarily.  I don't even want darcs spamming my local changes with
> conflict markers, I'd much rather have my local changes recorded in the
> repository so I can investigate any conflicts and resolve them carefully.
>
> The idea behind "record before pull" is just to package up your changes as
> a patch to protect against spamming due to conflicts or bugs in darcs.  It
> doesn't mean you have to keep that patch or push it - you can just unrecord
> or amend-record after pulling, to resolve conflicts or carry on working.
>
> Cheers,
>        Simon
>
>
>
>> 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.
>>
>> Simon
>>
>>
>> | -----Original Message-----
>> | From: Eric Kow [mailto:eric.kow at gmail.com] On Behalf Of Eric Kow
>> | Sent: 13 May 2009 03:44
>> | To: Simon Peyton-Jones
>> | Cc: tora at doc.ic.ac.uk; darcs-users at darcs.net
>> | Subject: case insensitivity and inconsistent state
>> |
>> | Hi Simon,
>> |
>> | I'm replying on the darcs-users mailing list because I think this is of
>> | general interest and also the beginning of a discussion.
>> |
>> | For the interested, this is a follow-up to Simon's comments on issue1453
>> |   http://bugs.darcs.net/issue1453
>> |
>> | On Thu, Apr 30, 2009 at 08:53:36 +0100, Simon Peyton-Jones wrote:
>> |>  a) Rather than saying "darcs failed:  File './stackTransitions.pdf'
>> already
>> | exists!", could you not emit a message saying
>> |>          "Looks as if your repo contains two files that differ only in
>> |>          the case of their filename.  Use darcs get --hashed"
>> |
>> | That's true.  This scenario is now covered by darcs using the --hashed
>> | switch by default (Trent Buck just submitted a patch yesterday).
>> |
>> |>  b) Similarly, in the other case I had, the failure said that the repo
>> |>  was now in an inconsistent state.  That's alarming, if (as was happily
>> |>  not the case) I'd had a lot of uncommitted changes in the tree.  *Was*
>> |>  it inconsistent?  Couldn't the message say something about using
>> |>  --hashed too?
>> |
>> | It was inconsistent.
>> |
>> | You're right in that the user interface for this isn't very good.  It's
>> | a question of generality and also ignorance.  The error message covers
>> | the general situation of "uh-oh! something unexpected happened in the
>> | pristine cache".  It is also ignorant of the fact that the underlying
>> | cause for this unexpected thing was case sensitivity.
>> |
>> | If this was a very frequently occurring cause of unexpectedness -- and
>> | it is *fairly* frequent -- it may indeed make sense to introduce an
>> | additional check with a nicer special-case error message, before
>> | throwing the more general error.
>> |
>> |>  [These suggestions apply even if --hashed is the default, in case you
>> use --no-
>> | hashed.]
>> |
>> | Better output would be helpful, but it comes at a price of
>> | special-casing the code.  I'm not sure what the right way to handle
>> | these sorts of tradeoffs are.  My inclination is to say that the
>> | joint probability of somebody simultaneously explicitly using
>> | --old-fashioned to force an old fashioned repo, getting a repository
>> | with filenames that differ only in case, and being on a case insensitive
>> | file system is low enough to make it more worthwhile to keep the code
>> | general.  But I could be wrong!  At the very least, the joint
>> | probability of just the latter two combined is high enough.
>> |
>> |>  c) What *does* happen if you use --hashed and there are two files with
>> |>  the same name? Does one overwrite the other?  Do you make X and X_0?
>> |>  Should darcs not at least tell the user that something
>> |>  presumably-unintended has happened.  Silence is not golden here.
>> |
>> | As far as internal consistency is concerned (by this I mean the patches
>> | and pristine cache), darcs will do the right thing.  Now for the working
>> | directory, it depends.  I don't mean to be flippant and write off the
>> | working directory.  Of course we should take the working directory
>> | seriously, but however seriously we take the working directory, we need
>> | to take the long-term history (pristine + patches) even more seriously
>> | than that.
>> |
>> | So what happens in the working directory?  That depends: darcs 2 and up
>> | have a habit of applying batches of patches (perhaps 100 at a time?) in
>> | memory before then re-applying the lot to disk.  This could mean that if
>> | the simultaneous co-existence of these files arises and vanishes within
>> | the same batch of patches, we get an effective no-op, in other words,
>> | you also get exactly the right behaviour in the working directory.   On
>> | the other hand, if the simultaneous co-existence happens to cross a
>> | patch boundary then some sort of havoc is possible.  You could
>> | accidentally apply patches for two different files (foo and Foo) to the
>> | same working directory file.
>> |
>> | The attached script illustrates the problem of two patches accidentally
>> | applying to the same file.  I think I should probably add this to our
>> | list of known bugs as a regression testing script.  Unexpected things
>> | are happening in the user's working directory, which is clearly far
>> | from ideal!  This has convinced me that Ganesh's plan (which he thought
>> | up during darcs hacking sprint #2) is the right way to go.  We need to
>> | allow multiple files (with a unique id) to be associated with the same
>> | name and somehow keep track of the correspondence between these unique
>> | IDs, the expected file name and the actual file name in the working
>> | directory (foo-1 vs foo-2).  This is long term Darcs-3 work, but at
>> | least, we do have some ideas on the matter.
>> |
>> | Thanks much for your comments!  Let us know if there is anything in
>> | particular we can do to help.
>> |
>> | --
>> | Eric Kow<http://www.nltg.brighton.ac.uk/home/Eric.Kow>
>> | PGP Key ID: 08AC04F9
>>
>
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090513/fb28a746/attachment-0001.htm>


More information about the darcs-users mailing list