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 [EMAIL PROTECTED]
>>>> * 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
_______________________________________________
darcs-devel mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-devel
