[darcs-devel] darcs patch: test: Exibit a falling test about rollback.

[Simon Marlow]

David Roundy wrote:
> On Thu, Jan 10, 2008 at 06:23:56PM +0100, Nicolas Pouillard wrote:
>> Excerpts from David Roundy's message of Thu Jan 10 18:08:59 +0100 2008:
>>> On Mon, Jan 07, 2008 at 03:43:40PM +0000, Nicolas Pouillard wrote:
>>>> Mon Jan  7 16:02:24 CET 2008  nicolas.pouillard at gmail.com
>>>>   * test: Exibit a falling test about rollback.
>>>>   Indeed  the only test about rollback was br0ken by a prior test that creates a
>>>>   directory  and  remove  read  permissions  to  it.  The  rollback test do some
>>>>   records  that  silently  fail  by lack of permissions, finally the rollback is
>>>>   cancelled since the named patch doesn't exist.
>>>>   This shows that rollback need some care.
>>> Thanks for the patch!
>>>
>>> I've actually been debating the idea of removing the rollback command.
>>> It's poorly implemented, and has been a source of confusion and problems.
>>> What do you think?
>> The source of problems was about hidden conflicts, right?
>> It's no longer a problem in darcs2, right?
>>
>> It's mainly a common use case when can no longer use amend-record.
>>
>> I  think that's also a great tool to temporarily revert a patch without having
>> two repositories.
>>
>> Moreover  this  kind of operation is waited when one know that patches must be
>> invertible.
> 
> The problem is that it's a pretty limited and counterintuitive command.
> You can't (currently) rollback a patch if there is a patch that depends on
> it which has been rolled back already.  And it doesn't affect the working
> directory, which makes certain things much easier (e.g. no need to deal
> with conflicts), but doesn't match what most folks actually want to do.
> Also, you can't add a note indicating *why* a patch was rolled back, which
> is a pretty big downside.
> 
> Having just chatted on this subject with a friend who walked by my office,
> I think what I'll do is implement a modified rollback that will allow you
> to undo more than one named patch at a time, and will make those changes in
> the working directory as well as recording them, and will allow you to
> provide a description of why you're rolling the change back... and will
> also (maybe not in the first draft) allow you to roll back just a subset of
> the primitive changes in those patches.  I think this'll be more useful and
> also easier to implement.

How about just applying the inverse of the patch (suitably commuted) to the 
working copy, leaving the user to record it, or record only parts of it, or 
whatever.  That seems like the most flexible solution.

Cheers,
	Simon