This message is an import of bug #251 from RT. In summary,
there are some cases with dependencies which don't work now with
'rollback'. They are solved by David Roundy's suggestion:

 Actually, I think that rollback should be rewritten to generate an entirely
 new patch, with a new patch name and comment. When a patch is rolled back, one
 really ought to explain the reason why. This wouldn't be such a hard change,
 it's just that I essentially never use rollback, so I don't tend to think about
 it.

###

I agree with David's assessment and would like to this update to
'rollback' happen.

	Mark

David, 

In this ticket you suggested re-writing rollback to generate an entirely new
patch.  However, more recently in issue202, you suggested eliminating it entirely:

"I'm seriously considering removing rollback for darcs 2.
With the way the conflict handling ended up turning out, it's no more
useful than in darcs 1, and it's always been a bad command. "

Would rewriting it as a described here be an alternative, or is it really best
to jut remove it? 

There are other open old issues with rollback:

rollback should not deny rolling back depended-upon patches
http://bugs.darcs.net/issue159

Pulling rollbacks messes up dependencies
http://bugs.darcs.net/issue157

(I looked for a way to officially associate tickets in Roundup besides
"Superseder", and I didn't see one. )

On Sat, Jan 05, 2008 at 03:43:41PM -0000, Mark Stosberg wrote:
> In this ticket you suggested re-writing rollback to generate an entirely new
> patch.  However, more recently in issue202, you suggested eliminating it entirely:
> 
> "I'm seriously considering removing rollback for darcs 2.
> With the way the conflict handling ended up turning out, it's no more
> useful than in darcs 1, and it's always been a bad command. "
> 
> Would rewriting it as a described here be an alternative, or is it really best
> to jut remove it? 

That would be a possibility, and would remove many of the problems with
rollback, but I suspect that rollback would continue to be a
not-very-useful command that confuses users.

I suspect that with darcs-2 repositories we can do much better than that
with other sorts of commands.  e.g. why not allow reverting of just some of
the changes in a particular named patch?

I think that better semantics (unfortunately rollback is a good command
name with poor semantics, and I'm not sure that changing its meaning would
do our users a favor) would be to have a rollback-like command generate no
patch, but instead apply inverse changes in the local repository.  So it'd
be a way of reverting an unrecorded change.  Then you'd use record to
record these changes as a new patch, possibly along with some additional
changes.

I'm not sure of a name for this new feature, but lean against calling it
rollback simply because that name already has a meaning for darcs users.
Perhaps if we removed rollback entirely from one release, then we could add
it back with a different meaning?

> There are other open old issues with rollback:
> 
> rollback should not deny rolling back depended-upon patches
> http://bugs.darcs.net/issue159

This would be an example of a bug that could be fixed by simply reverting
changes as suggested above (except that revert is a poor word, we've used
most of the good words for this kind of effect).

> Pulling rollbacks messes up dependencies
> http://bugs.darcs.net/issue157

This one would also be fixed by either change.

> (I looked for a way to officially associate tickets in Roundup besides
> "Superseder", and I didn't see one. )

Alas, I don't know of such a thing, so posting URLs like you've done is
perhaps the best we can do.  Thanks for doing all this bug triage, by the
way! (as you may have noticed, you motivated me...)
-- 
David Roundy
Department of Physics
Oregon State University

> I'm not sure of a name for this new feature, but lean against calling it
> rollback simply because that name already has a meaning for darcs users.
> Perhaps if we removed rollback entirely from one release, then we could add
> it back with a different meaning?

Here's my take. I've been using darcs since pre 1.0, and filed the two
bug related bug reports referenced here long ago. My experience with
rollback was to decide it was a useful idea, and then use it enough to
find it was broken, and then realize I should generally avoid it, while
forgetting exactly what was wrong over time.

I vote for modifying rollback but keeping the same name, as long as the
functionality is similar, and importantly-- that it works.

Too many times I have seen software suffer over time, including my own,
in the name of backwards compatibility.

I think we agree the current 'rollback' is rather broken. If the best
way to fix it is major surgery, I say go for it.

The common user experience could be one of confusion, but it could also
be one of relief and appreciation that something potentially useful was
broken and has been fixed.

Confusion could be mitigated by clear documentation about the change--
highlighting the "all new rollback" in release announcements and so
forth.

     Mark

This feature has been implemented in unstable now. Thanks, David!