[darcs-users] rollback should apply inverse patch to current as well.

[Andrew Pimlott]

On Sat, May 08, 2004 at 07:20:36AM -0400, David Roundy wrote:
> On Fri, May 07, 2004 at 05:35:05PM -0700, Adam Megacz wrote:
> > Aside from this one command (rollback), darcs has the nice invariant
> > that all patches applied to the repository have also been applied to
> > the working directory, no matter what (of course the opposite is not
> > true, otherwise 'darcs record' would be pointless).

It seems that either behavior might be desirable in some cases,
depending on whether I want to roll-back the patch temporarily (a
variation on unrecord) or permanently (a variation on unpull).  You
might even argue that undo patches should be an optional feature of
unrecord or unpull, instead of its own command.

There is a separate problem with the current behavior.  If rollback is
meant to act like unrecord, it should be possible to "undo" the rollback
by recording (assuming that there are no other working changes).
However, if you rollback a file add, darcs forgets about the add.
Compare:

    % mkdir a     
    % cd a 
    /a% darcs inittree
    Successfully initialized tree!
    /a% touch foo
    /a% darcs add foo
    /a% darcs record -a -m foo
    Finished recording patch 'foo'
    /a% darcs unrecord

    Tue May 11 14:52:07 PDT 2004  andrew at pimlott.net
      * foo
    Shall I unrecord this patch? [yNvq?] y
    Finished unrecording.
    /a% darcs whatsnew
    {
    addfile ./foo
    }

Good!

    /a% darcs record -a -m foo2
    Finished recording patch 'foo2'
    /a% darcs rollback

    Tue May 11 14:52:19 PDT 2004  andrew at pimlott.net
      * foo2
    Shall I rollback this patch? [yNvq?] y
    Finished rolling back.
    /a% darcs whatsnew
    No changes!

Bad.

> I think the reason rollback doesn't apply to the working directory, is that
> if it did, you'd be unable to rollback changes that fail to commute with
> any changes you have in your working dir.  e.g.

But, per my other reply, you already can't rollback changes that fail to
commute with other recorded changes, so this isn't much of a loss.

> I have a patch
> [bug
> David Roundy <droundy at abridgegame.org>**20040508111354] {
> hunk ./foo 1
> +this is a bug
> }
> 
> I have in my working directory
> $ darcs whatsnew 
> {
> hunk ./foo 1
> -this is a bug
> +this is not a bug
> }
> 
> I now would be unable to rollback the original buggy patch, since its
> inverse patch can't be applied to the working directory.

Morever, I think it's probably harmful and surprising to rollback the
original patch without flagging a conflict.  If there is a conflict, the
user should know about it.  I don't know how you'd handle this, though.
Maybe put a merger in pending that causes the conflict to come up when
you record.  (I've suggested this before because it sounds cool and
powerful, but I don't know if it would really work.)

Andrew