Comment 36 for bug 45719

I experimented with "bzr revert" a bit to understand how it works, and this is not what I am looking for. Let me explain.

The problem is that, as far as I understand, "bzr revert" does not change the revision number of the working tree (and/or branch?), as reported by "bzr revno". Thus, to bzr, revert is equivalent to applying a bunch of manual changes to the current revision to make it identical to an old revision. Indeed, after a "bzr revert" to an earlier revision, the command "bzr status -V" reports all the changes made, which can then be committed. I would expect that executing "bzr update" at this point would do nothing since the tree is seen as up-to-date, assuming no one else committed anything (I didn't try this though). That would make sense, since bzr is still comparing the working tree to the latest revision of the branch. Now, this behaviour is fine if the idea is to actually undo some changes, as opposed to simply inspecting & toying with some previous versions. If I simply want to inspect previous versions, I wouldn't want "bzr status -V" to list all the files changed between the older revision and the current one.

The behaviour I would expect from "bzr update -r" is as follows (I haven't been able to try Martin's implementation yet). Let's assume the most recent revision committed, and also that of my working tree, is rev 100. Assume I have manually modified one file, named foo. At this point "bzr status -V" should tell me that only foo has been modified, and "bzr revno" should return "100". Now, I execute "bzr update -r 95". This should change all files in my working tree to their state as of rev 95, except for those I have manually edited, which should be left as is. Following this, if I execute "bzr status -V", only the file foo should be listed as edited or added or deleted (assuming it was under revision control in rev 95). Furthermore, the command "bzr revno" should now tell me that I am at revision 95. If I now perform "bzr update" to bring the working tree back up to the latest version (100), foo should again be left alone. While scrolling through history using "bzr update", I would not expect "bzr commit" to commit any changes except to those made to "foo", since only foo is listed as changed by "bzr status -V".

Another way to look at all this is that "bzr update -r 95" should give me a working tree in the same as "bzr checkout -r 95" (I assume "bzr revno" would tell me that the current revision is 95 after such a checkout). In contrast, "bzr revert -r 95" should give me a working tree in the same state as that produced by the command "bzr checkout (latest rev, i.e. 100)", then followed by a set of patches to make the working tree be identical to that of rev 95. These patches can then be committed (and are listed by "bzr status").

One final comment regarding the behaviour of bzr revert or update when some files have been edited. I would advocate that these files are *not* changed or renamed when doing a "bzr update". This is what happens with CVS. Thus if I have modified foo, then "bzr update -r 95" followed by "bzr update -r 100" should leave my tree *exactly* like it was before. I would absolutely *not* want to have my edits show up in a backup ('.~#~'-appended) file, unlike what happens with a revert.

Indeed, I don't actually agree with how revert makes backups of edited files. This makes it impossible to undo the effects of a revert with a subsequent revert, if some files were edited. Edited files should be sacred. As far as I'm concerned, bzr should never modify or rename them without the user's explicit intent.

Any comments?

Finally, I would also suggest that the documentation for revert be updated to make it clear that the revno does not change. Should I file a bug for this?

Regards,

Julien