This is a request for comment as well as a wish.  

Perhaps darcs whatsnew should have the following sanity check: if there is
nothing new before I pull or apply patches, there is nothing new after I apply
them.  We can't do much more checking than that (because if there are changes to
the pending patch, they would need to be commuted), but I suspect that this very
simple case could give us some early warning about potential pending patch bugs.

I'm not sure if this should be tolerant or not.  If the sanity check fails, do
we want a "Bug in darcs" or do we just want a big warning?

The context is that I have been thinking about Claus and his battles with
http://bugs.darcs.net/issue693 and http://bugs.darcs.net/issue1034 this morning.
 One of his insights is that it is a pity we can't reason backwards about why
mysterious bugs happen.  Our inability to do this is partly because darcs
doesn't record the fact that things go wrong (e.g. having to tolerantly apply
patches, issue1010)... but sometimes darcs /can't/ in general know that
something has gone wrong (for example, with pending patch bugs).  The invariant
I propose is a just special case where we actually have a clear definition of
"wrong"... so maybe we should exploit it.

>Perhaps darcs whatsnew should have the following sanity check: if there is
>nothing new before I pull or apply patches, there is nothing new after I apply
>them.  We can't do much more checking than that (because if there are changes to
>the pending patch, they would need to be commuted), but I suspect that this very
>simple case could give us some early warning about potential pending patch bugs.

You mean that 'darcs pull' etc should check that 'darcs whatsnew'
output doesn't change? That sounds useful. Why can't it be extended
to non-empty 'darcs whatsnew', though?

If the pull conflicts with local changes, we get a conflict message. In
all other cases, the output of 'darcs whatsnew' should not change with
pull, right? Something like:

    whatsnew_{pre} =_{modulo conflicts} whatsnew_{post}

>I'm not sure if this should be tolerant or not.  If the sanity check fails, do
>we want a "Bug in darcs" or do we just want a big warning?

Warnings can get lost easily, so they should be repeated until resolved
(issue1010). If there is an obvious bug, immediate reporting should be 
encouraged. Apart from those two concerns, users would like to be
able to get unstuck quickly. But just continuing will maintain the status
quo, with surprising follow-on issues, possibly at a much later time
when the warning is long forgotten.

>The context is that I have been thinking about Claus and his battles with
>http://bugs.darcs.net/issue693 and http://bugs.darcs.net/issue1034 this morning.
>One of his insights is that it is a pity we can't reason backwards about why
>mysterious bugs happen.  

Actually, the point about reasoning backwards is much stronger:
given a darcs fix description and a repo in which errors occured,
someone should be able to determine whether and where the fix
would have affected the repo history, in particular, where in the
repo history the pre-fix darcs would have failed when the after-fix 
darcs would have succeed.

>Our inability to do this is partly because darcs doesn't record the 
>fact that things go wrong (e.g. having to tolerantly apply patches, 
>issue1010)... but sometimes darcs /can't/ in general know that
>something has gone wrong (for example, with pending patch bugs).  
>The invariant I propose is a just special case where we actually 
>have a clear definition of "wrong"... so maybe we should exploit it.

That is more related to your concern that darcs forensics are
currently not as well supported as they could be, making it too
difficult to reproduce bugs for fixing, let alone knowing when
they're fixed. And making sure that issues are reported (by darcs)
as early as possible (when users still have the context of what went
wrong) certainly sounds like a step in the right direction.

Claus

On Wed, Sep 17, 2008 at 13:33:58 +0100, Claus Reinke wrote:
> If the pull conflicts with local changes, we get a conflict message. In
> all other cases, the output of 'darcs whatsnew' should not change with
> pull, right? Something like:
>
>    whatsnew_{pre} =_{modulo conflicts} whatsnew_{post}

Because whatsnew /can/ change with pull because of commutation.  If you
edit file foo and pull a patch renaming foo to bar, then your whatsnew
should now report that you have edited file bar.

So this check would be a a lot less straightforward than simply checking
the case where there is nothing new.  A fancy check that works modulo
commutation might be prone to the same kinds of bugs that pending is
susceptible to, so I would not advocate it.

On Wed, Sep 17, 2008 at 4:24 AM, Eric Kow  wrote:
> Perhaps darcs whatsnew should have the following sanity check: if there is
> nothing new before I pull or apply patches, there is nothing new after I apply
> them.  We can't do much more checking than that (because if there are changes to
> the pending patch, they would need to be commuted), but I suspect that this very
> simple case could give us some early warning about potential pending patch bugs.

I'm not entirely clear what you mean here.  I think you're proposing a
change to darcs pull and apply, not a change to whatsnew?

> I'm not sure if this should be tolerant or not.  If the sanity check fails, do
> we want a "Bug in darcs" or do we just want a big warning?

I'd say just a small warning.  There's nothing to prevent users from
modifying the working directory while pulling.  It's not really very
wise to do so, but in many cases it isn't harmful, and it should never
cause corruption (of anything but the working directory, they could
certainly lose the changes they make while darcs is changing the same
file, but that's to be expected).  We don't want to claim we've got a
bug when a user is doing something reasonable, like editing one file
while darcs pulling changes that he knows don't affect that file.

> The context is that I have been thinking about Claus and his battles with
> http://bugs.darcs.net/issue693 and http://bugs.darcs.net/issue1034 this morning.
>  One of his insights is that it is a pity we can't reason backwards about why
> mysterious bugs happen.  Our inability to do this is partly because darcs
> doesn't record the fact that things go wrong (e.g. having to tolerantly apply
> patches, issue1010)... but sometimes darcs /can't/ in general know that
> something has gone wrong (for example, with pending patch bugs).  The invariant
> I propose is a just special case where we actually have a clear definition of
> "wrong"... so maybe we should exploit it.

Sounds reasonable, except of course that it doesn't necessarily
indicate a bug.  Also note that this invariant is also violated when
there are conflicts--and correctly so, so we'd need to be a bit more
careful than just checking the before and after state.

David

On Wed, Sep 17, 2008 at 14:15:38 -0000, David Roundy wrote:
> > Perhaps darcs whatsnew should have the following sanity check: if there is
> > nothing new before I pull or apply patches, there is nothing new after I apply
> > them.  We can't do much more checking than that (because if there are changes to
> > the pending patch, they would need to be commuted), but I suspect that this very
> > simple case could give us some early warning about potential pending patch bugs.
> 
> I'm not entirely clear what you mean here.  I think you're proposing a
> change to darcs pull and apply, not a change to whatsnew?

Yes, sorry, I must have confused myself!  The sanity check is in darcs
pull apply, but it checks the whatsnew output (which is probably where
the confusion came from)

> Sounds reasonable, except of course that it doesn't necessarily
> indicate a bug.  Also note that this invariant is also violated when
> there are conflicts--and correctly so, so we'd need to be a bit more
> careful than just checking the before and after state.

Ah yes, I had not considered that possibility.  That slightly reduces
the usefulness of this sanity check though :-(  I dunno, all I wanted
was to find a way to detect new variants on issue693 before users get
bitten by them.