Revert implmentation and how to undo a bzr remove

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On Wed, 2005-04-27 at 19:52 +1000, Aaron Bentley wrote:
> 
> 
>>I should mention that the merge code can do revert (or switch, update,
>>etc).  It can be restricted to operate only on particular files.
> 
> 
> Two points on that:
> 
> Revert is such a common command that I think it needs at least to have
> an easily visible interface.

Agreed.  I don't think users should have to do "merge ./@ .".  In fact,
I expect that in the near future, we'll implement safeguards so that the
merge command will not operate on trees with uncommitted modifications.
 At that point, the merge command can no longer be used for revert.  So
I meant that users could type "revert [-r REVNO] file1 file2" to invoke
the merge code.

> In tla/baz, undo is implemented by calculating a changeset and applying
> it in reverse.  Experience shows it often fails on one of these stages,
> which is very unfortunate because revert is a command people want to use
> to recover a messed-up tree.  It's important that revert work even when
> something has happened that makes other commands fail.

That's something I hadn't thought of.  Still, there aren't very many
ways to cause the merge code to fail.  The two ways I can think of are

1. having a directory named 'temp' in the tree root.  The temp dir
serves as a directory lock during merge application.  Obviously, we can
call it something else, or use mkdtemp if we don't want the
directory-locking property.

2. having a tree in which the inventory is broken (e.g. two files with
the same ID).

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCcFdM0F+nu1YWqI0RAh+tAJ49p+xsZQekCokFnbMvF9yyCpB2wwCfR01l
aqSXAmjNbJQo6kSAisZ2Efg=
=rKiX
-----END PGP SIGNATURE-----