[darcs-users] case insensitivity and inconsistent state
Simon Marlow
marlowsd at gmail.com
Wed May 13 23:38:24 UTC 2009
On 13/05/09 21:53, Jason Dagit wrote:
> 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
Ah yes, that's another reason to do "record before pull": you don't need
to do dry runs, because a pull is reversible. Just revert any conflict
markers, and unpull the patches that were pulled.
Thanks for the other comments - I've never really got on with external
merge commands, but that maybe a failing of mine rather than the
tool(s), I'm not sure.
Cheers,
Simon
> 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
> <mailto: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
> <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 <mailto:tora at doc.ic.ac.uk>;
> darcs-users at darcs.net <mailto: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 <mailto: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/20090514/6f8fbcb2/attachment-0001.htm>
More information about the darcs-users
mailing list