Is this the expected revert behaviour ?

[Bryan O'Sullivan]

On Fri, 2006-05-05 at 10:20 +0200, Christian Boos wrote:

> This bit made me think we should clarify the Mercurial terminology:
> here we speak of "the parent of the working directory", but that's
> not done consistently across the documentation.

Right.  I think that's one of the principal reasons why people get
confused by merge; we just don't explain clearly what update and merge
are doing with respect to the working directory.

> So I'd propose something like:
> 
> revert [-r REV] [NAME]…
>     Change the content of the working directory to match the specified
>     revision. without changing the working directory parent
> 
> update [-b TAG] [-m] [-C] [-f] [REV]
>     Change the working directory parent to the specified revision. The
>     content of the working directory will change depending on the options.

I think these look very good.  The only problem is that the automated
help currently prints just the first line of a command's doc comment.
In order to manage these useful additions, it should perhaps be twiddled
to print the first paragraph instead.

> Also, we should mention in the WorkingDirectory glossary page that the
> working directory has at any time a current parent revision, possibly two
> after a merge.

Yes, this needs to be proclaimed loudly.  Could you update the wiki,
please?

> More related to the original topic, also add a note that after an "hg 
> merge",
> "hg revert" will pick one of the working directory parent (the first?)
> as the revision it should revert to.

Right.  In fact, if the working dir has two parents, revert should bomb
out if you don't explicitly state a changeset to revert to, because any
other behaviour will lose changes from one or other parent.  I'll file a
bug against this.

I'm glad you brought this topic more to the forefront.  Thanks!

	<b