[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