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

David Roundy droundy at abridgegame.org
Sat May 8 11:20:36 UTC 2004

On Fri, May 07, 2004 at 05:35:05PM -0700, Adam Megacz wrote:
> David Brown <darcs at davidb.org> writes:
> > As I understand it, rollback, and unrecord do not back out the changes
> > in the working directory.
> This makes sense for unrecord, since you're deleting the patch.
> However, in the case of rollback, you're actually *applying* a patch
> (the inverse).
> 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).
> I kinda assumed this was a basic rule-of-darcs, but I guess it's not
> true.
> Also, this begs another question: if a patch has been applied to the
> repo but not to the working directory, how do you make darcs apply it
> to the working directory?  Pull it from yourself?

Darcs revert will let you do this, although of course that will prompt you
for *all* your changes, so it's not really what you're looking for.

> So, I'd suggest either mentioning this in the documentation (note:
> rollback is the only way to wind up with a patch in the repo which
> hasn't been applied to current) or else have rollback apply the
> inverse patch to the working directory too, and then we could list
> this invariant in the documentation, which would help people
> understand the relationship between the repo and working directory.

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.

I have a patch
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.  It's an awkward
situation... and I guess we could just say that in this case you can't
rollback, or that you'd have to rollback on a clean copy of the repository
and then pull (which would result in merge conflicts).  Or rollback itself
could merge the inverse patch with your unrecorded changes, but I really
don't like that idea.

On the other hand, making rollback the equivalent of unpull (as you
suggest) would be nice in other ways, one of which is that unpull itself is
a "dangerous" command (since it can lose information) so rollback could be
billed as a "safe" replacement for unpull.
David Roundy

More information about the darcs-users mailing list