[darcs-users] case insensitivity and inconsistent state

Simon Peyton-Jones simonpj at microsoft.com
Thu May 14 08:50:52 UTC 2009


Thanks.

However, dry-run doesn't help.  What I want is precisely

-          to pull the new patches

-          fix the conflicts
Dry-run doesn't help with that.

The two problems I'm highlighting are

-          (minor) the conflict marking stuff; thanks for advice about that

-          (major) the possibility that my working files might be seriously screwed up

Simon


From: dagitj at gmail.com [mailto:dagitj at gmail.com] On Behalf Of Jason Dagit
Sent: 13 May 2009 21:54
To: Simon Marlow
Cc: Simon Peyton-Jones; darcs-users at darcs.net; tora at doc.ic.ac.uk
Subject: Re: [darcs-users] case insensitivity and inconsistent state

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<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/6ad3f770/attachment-0001.htm>


More information about the darcs-users mailing list