[darcs-users] locking problem and "what is a patch?"

[David Roundy]

On Mon, Jun 21, 2004 at 10:26:16PM +0200, Martin Schaffner wrote:
> Today I had again the following problem on Mac OS X:
>    darcs failed:  Failure creating temp named _darcs/prefs/boring
> Your suggestion to do DARCS_SLOPPY_LOCKS=1 helped... After some time, the
> problem went away again, and this wasn't needed anymore - Maybe right
> after the first use of this variable? Next time I'll check.

I think the locking bugs may be fixed now...

> I also had the "Yikes inconsistent pending" bug - happened after a pull 
> from another repo had a conflict, maybe with local changes, is that 
> possible? Anyway, a "darcs get" of the corrupted archive got me working 
> again...

Did you keep this repo? It is definitely possible to have a conflict with
local changes, but if this gets you a problem in pending, that's bad.

> Man, I hate those long-scrolling binary patches, which usually even 
> push the filename they belong to out of the  scrollback buffer - David, 
> are you working on this, or would a contribution of me be welcome 
> (although I'd have to learn Haskell on-the-go)? I would like to have 
> hunk and oldhex/newhex patches not be shown by default, but be given a 
> (V)iew option in addition to the usual "yes/no/wait/..." options, which 
> would then show it - this solution seems simplest to me, and simplicity 
> is key to robustness.

I've now made darcs never output binary patch contents to a terminal,
although they'll still be output if you pipe through a command a whatsnew
or something like that.

I don't care for the idea of not showing hunk contents by default, since it
means if you want to see what the hunk is, you'd have to type an extra
character, and I almost always want to see what changes I'm recording.
Perhaps something like a --summary flag for record is in order.

> BTW, while using darcs, I saw that there are two things darcs calls 
> "patches": The hunk/oldhexnewhex/addfile/rmfile things for which "darcs 
> record" asks if I want to apply them, and the things that get 
> pushed/pulled and are stored in _darcs/patches. I propose to call the 
> former "changes", as to not confuse the user. darcs record could ask 
> something like "do you want to add this change to the new patch?". As I 
> see it, you have atomic, non-mergeable "patches", which can be recorded 
> from "changes" you made. Unless, of course, there is semantically no 
> difference between these two things - which would IMO require the 
> possibilty to merge multiple patches together into one, and/or to break 
> up a patch into smaller patches, up to the individual changes that are 
> asked to be added by "darcs record".

The idea behind the terminology (which is not necesarily consitently
applied) is that a "patch" is a representation of a "change".
hunk/addfile/rmfile are "primitive patches" representing "primitive
changes".  "Named patches", such as

Tue Jun 22 05:46:15 EDT 2004  David Roundy <droundy at abridgegame.org>
  * fix file modification time bug.

represent "named changes".

This means that one can often use "change" and "patch" interchangeably.
Usually I would prefer "change", but in practice "patch" is usually used,
because the terminology described above didn't exist (it was a user's
suggestion) when most of darcs was written.

A primitive change, an anonymous change (i.e. an unrecorded set of
primitive changes) and a named change are all equally valid changes, but
only named changes can be moved from one repository to another, for obvious
practical reasons.

The pending that can have conflicts (i.e. the "Yikes" error) is an
anonymous set of changes that haven't been recorded--mostly moves and adds.
-- 
David Roundy
http://www.abridgegame.org