Is this the expected revert behaviour ?

[Sébastien Pierre]

Le 06-05-05 à 19:13, Christian Boos a écrit :

> Sébastien Pierre wrote:
>> ...
>> While revert has a connotation of "backward in time", update has a
>> connotation of "forward in time" (but maybe it's a cultural thing) --
>> but both do the same operation, the only difference being the fact  
>> that
>> the parent is set or not.

> When you do an update, it's like you're moving the "referential"
> of your working directory, and this can be backward or forward
> in the history.

> When you do a revert, you stay in the same referential and you
> simply "revert" the changes. Again, regarding local modifications,
> one could consider they were "moved backward in time".

This is actually a rather good clarification of the terms. However, I  
still find the terms confusing, because they do almost the same  
things, but the difference being the change in referential.

Can somebody, especially a newbie, intuitively guess that "update"  
and "revert" have the same behaviour, excepted the referential change ?

My first impression was that when "updating" my files, I would  
actually stay in the same referential, and then, only move to the new  
referential when I commit.

$ hg update 30 (I update my files to the content of r30 from r26)
$ hg commit (I commit my changes, so I will be either at r30 or in  
direct child branch of r30, if I made/had local changes)

This seems to me as clearer, and would make "revert" useless : using  
the "-m" flag would have the same effect as the current "update"  
behaviour.

When "update -m" from A->B

  - If no local changes
    - and there is a path from A to B, then new parent is B
    - otherwise B is added to parents, and conflicts should be resolved

  - If local changes
    - if -C option, changed files are moved to .orig and we fallback  
to the above case
    - or if B is a descendant/ancestor of A and no locally changed  
file has changed between A and B, we set the new parent to B
    - otherwise we add B to the parents, and conflicts should be  
resolved

Does this make sense ?

> Here's my updated proposal for the command help:
>
> update [-b TAG] [-m] [-C] [-f] [REV]
>   Change the working directory's parent revision, keeping local  
> changes.
>
> merge [-b TAG] [-f] [REV]
>   Add an extra parent to the working directory, for preparing a merge.
>
> reset [-b TAG] [-f] [REV]
>   Reset the working directory to have a single parent and no local  
> changes.
>
> revert [-r REV] [NAME]…
>   Change only the content of the working directory to match the one of
> a revision.

This makes a lot of sense, and the link between every command is  
clearer. However, I really do think that "revert" should be removed,  
as I don't see what it brings besides complexity.

  -- Sébastien