Issue 31: running "monotone update" will delete removed files even if they are modified

Reported by Unknown User, Nov 25, 2005

(This entry was imported from the savannah tracker, original 
location: https://savannah.nongnu.org/bugs/index.php?15058)

see 
http://lists.gnu.org/archive/html/monotone-devel/2005-10/msg00249.htm
l

Comment 1 by Markus Wanner, Feb 4, 2008

Added unit test update_with_pending_modification, which checks for 
that bug.

Comment 2 by Stephen Leake, Aug 15, 2008

fixed in branch net.venge.monotone.automate_show_conflicts; it now 
reports a content/drop conflict.

Comment 3 by Thomas Keller, Aug 11, 2010

Is this really fixed? The test in question is still shows the 
expected failure.

Comment 4 by Stephen Leake, Aug 12, 2010

Clearly not fixed.

nvm.automate_show_conflicts only fixed stuff in merge, not update. 
So I must have been confused when I posted comment #2.

This _will_ be fixed when I get around to improving update to handle 
conflicts properly.

Comment 5 by Thomas Keller, Feb 22, 2011

It's possible to block the deletion at the time we're simulating the 
workspace actions, just as we do for unknown files in deleted 
directories. Surely, this is ugly since I have to re-calculate the 
sha1 hash for all deleted contents for this check again (and this 
might be slow), so of course a better solution would be to somehow 
hook into the merge process, which also would make the consecutive 
warning messages not so confusing.

On the other hand, refactoring (re-using) the 
`--move-conflicting-files` machinery for this use case also has its 
charm, something like `--fix-conflicting-files` that would copy the 
changes of the specific file into _MTN/resolutions and afterwards 
revert the file in the workspace to its original contents, so the 
update / delete can happen without problems. Thirdly, this could 
also be useful for conflicting updates, that would otherwise let the 
3-way merge tool of choice pop up.

Example output of the xfailing test 
`update_with_pending_modification` that runs on an mtn with the 
attached patch incorporated:

mtn: selected update target 47865ec3f917ee38393ec3f72a216923845d4ade
mtn: [left]  c1a3a631a5d670e6fdba5fe124ceaa87549f5699
mtn: [right] 47865ec3f917ee38393ec3f72a216923845d4ade
mtn: warning: Content changes to the file 'file2'
mtn: warning: will be ignored during this merge as the file has been
mtn: warning: removed on one side of the merge.  Affected revisions 
include:
mtn: warning: Revision: c1a3a631a5d670e6fdba5fe124ceaa87549f5699
mtn: warning: cannot drop file 'file2' with local changes
mtn: misuse: re-run this command with --move-conflicting-paths to 
move conflicting paths out of the way.

issue-31.diff - 1.06 kB - view

Comment 6 by Thomas Keller, Feb 28, 2011

By the way, src:work.cc@t:monotone-0.99.1#1916 and the following 
lines contains some code that actually _should_ fix the above bug 
already, but apparently something is wrong there.