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.
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.