backout reports an arguably spurious conflict when backing out the creation and modification of a file

[Tom Anderson]

Morning all,

I don't always back out old changesets, but when i do, i back out 
several at once. This is a natural consequence of the "commit early, 
commit often" philosophy, which my colleagues and i vigorously embrace.

However, backout does not always handle this as gracefully as would be 
ideal. In particular, if we have added a file in one changeset and 
modified it in a later one, then if i back out the later (modifying) 
changeset, backout is skittish about removing the file when i then back 
out the earlier (creating) changeset.

By way of example:

$ hg --version
Mercurial Distributed SCM (version 2.3)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2012 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ hg init foo
$ cd foo
$ # this file and changeset are irrelevant; they're just there to give 
us some history
$ hostname >hostname
$ hg add hostname
$ hg commit -m 'added hostname'
$ date >date
$ hg add date
$ hg commit -m 'added date'
$ sleep 1; date >date
$ hg commit -m 'updated date'
$ hg log
changeset:   2:4fd92dcb8b2a
tag:         tip
user:        Tom Anderson <tom.anderson at timgroup.com>
date:        Mon Aug 06 12:11:28 2012 +0100
summary:     updated date

changeset:   1:d35284536be0
user:        Tom Anderson <tom.anderson at timgroup.com>
date:        Mon Aug 06 12:11:27 2012 +0100
summary:     added date

changeset:   0:80e53477a8de
user:        Tom Anderson <tom.anderson at timgroup.com>
date:        Mon Aug 06 12:11:27 2012 +0100
summary:     added hostname

$ hg backout 2 -m 'backing out 2'
reverting date
changeset 3:79460afd05d0 backs out changeset 2:4fd92dcb8b2a
$ hg backout 1 -m 'backing out 1'
removing date
remote changed date which local deleted
use (c)hanged version or leave (d)eleted?

If i respond 'd', things continue:

0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg status
R date

This is the correct outcome. However, it would have been nice if i 
hadn't been prompted about what to do. I was pretty baffled when i first 
saw that; in the real case, it referred to a file i wasn't familiar 
with, because i was backing out someone else's changes. It didn't take 
long to work out that it was a spurious complaint, but it would have 
been nice if i hadn't had to.

I understand why this is happening: the file i am removing has indeed 
been modified by later changesets. However, the state that it is 
currently in is identical to the state that resulted from the changeset 
i am trying to back out, and so really, it's clean and safe to remove it.

This isn't exactly a bug, but it strikes me as a rough edge that could 
be smoother. Should i raise a bug for this?

tom

-- 

Tom Anderson | Developer | +44 20 7826 4312 | timgroup.com 
<http://timgroup.com/>

STATEMENT OF CONFIDENTIALITY: The information contained in this 
electronic message and any attachments to this message are intended for 
the exclusive use of the addressee(s) and may contain confidential or 
privileged information. If you are not the intended recipient, please 
notify Tom Anderson at TIM Group at tom.anderson at timgroup.com and 
destroy all copies of this message and any attachments.

TIM Group is the trading name for YouDevise Limited. YouDevise Limited 
is registered in England, No. 3331176. Registered office: 3 Copthall 
Avenue, London, EC2R 7BH.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120806/2fdf6df0/attachment-0002.html>