[issue470] Inconsistent update behaviour for modified files when going in the past

[Phil]

New submission from Phil <hg.bt.web at secdev.org>:

When updating to (grand...) parents, hg reverse changesets for unmodified files,
but not for modified files. The latter is inconsistent with the former but also
with the fact it does re-apply changesets when updating to (grand...) childs.

Recipe:
$ hg init
$ touch foo
$ hg add
adding foo
$ hg commit -m foo
$ echo bar >> foo
$ hg commit -m bar
$ echo barbar >> foo
$ hg update 0
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Here, changeset 1 has not been reversed (it would have lead to a merge and a
conflict resolution).

Then if we go up again:
$ hg update 1
merging foo
conflicts detected in /tmp/test/foo
<<<<<<< /tmp/test/foo
bar
barbar
=======
bar
>>>>>>> /tmp/foo~other.hu5Ubo

It tris to apply changeset 1 (expected behaviour), but because the first update
did not reverse it, it means it will be applied twice and we have to manage a
conflict between changeset 1 and itself!

In my opinion, consistent behaviour should have been to reverse all changesets
at cost of merging and conflict resolution. Exactly the way it is down when
updating to childs.

----------
messages: 2654
nosy: Phil
priority: urgent
status: unread
title: Inconsistent update behaviour for modified files when going in the past

____________________________________________________
Mercurial issue tracker <mercurial-bugs at selenic.com>
<http://www.selenic.com/mercurial/bts/issue470>
____________________________________________________