Mercurial wipes repository history!?

[Masklinn]

On 8 avr. 2010, at 17:25, Jon Ribbens <jon- 
mercurial at unequivocal.co.uk> wrote:
> On Thu, Apr 08, 2010 at 10:08:50AM -0500, Mark A. Flacy wrote:
>>   On Thu, 2010-04-08 at 15:54 +0100, Jon Ribbens wrote:
>> It is in that log, yes. It was not in the scenario we were trying to
>> replicate. It is also not at all clear to me that "clone" should be
>> a roll-backable operation (it is evidently not clear to the hg  
>> authors
>> either, since a local clone is not roll-backable and a remote clone
>> is.)
>>
>>   "clone" is a transaction.  The fact that a local clone cannot be  
>> rolled
>>   back is an error.
>
> Can you think of a use case that illustrates why anyone would ever
> want to roll back a "clone" - why it would ever *not* be the wrong
> thing to do?
Just because it isn't generally useful doesn't mean it's a bug.

rm -rf / generally isn't a good idea, but it's not rm's job to decide  
what is or isn't a good idea to call it on. Likewise, rollback has a  
simple contract: roll back the last transaction.

You can argue that it's not always clear what the last transaction  
*is*, you can argue that the transactional characteristics of commands  
is undocumented, you can argue that there are bugs in rolllback (e.g.  
rollbacking a local clone) but I don't see how you can argue that  
there are situations where rollback should refuse to fullfil it's  
contract.