<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.3">
</HEAD>
<BODY>
On Thu, 2010-04-08 at 15:54 +0100, Jon Ribbens wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Thu, Apr 08, 2010 at 04:45:39PM +0200, Benoit Boissinot wrote:
> A transaction is an operation modifying the history. As far as I can
> tell from your command log, the last transaction *is* the clone
> operation.
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.)
</PRE>
</BLOCKQUOTE>
<BR>
"clone" is a transaction. The fact that a local clone cannot be rolled back is an error.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> > Surely it would be much better to make the remote behaviour fail too?
> > Suddenly vaporising the entire repository without warning is hardly
> > good behaviour to be more widely introduced!
</PRE>
</BLOCKQUOTE>
<BR>
No, it would be better to make the local clone behave correctly on<BR>
rollback. That way the rollback command behavior is consistent and<BR>
users have the chance to create a proper mental model of the rollback<BR>
operation.<BR>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
Mark A. Flacy <<A HREF="mailto:mflacy@verizon.net">mflacy@verizon.net</A>>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>