[Monotone-devel] Updated Issue 31 - running "monotone update" will delete removed files even if they are modified (monotone)

[code]

Hello,

The following issue has been updated:

31 - running "monotone update" will delete removed files even if they are 
modified
Project: monotone
Status: New
Reported by: Unknown User
URL: https://code.monotone.ca/p/monotone/issues/31/
Labels:
 Type:Incorrect Behavior
 Component:Working Copy
 Priority:Medium

Comments (last first):

# By Thomas Keller, Feb 28, 2011:

By the way, src:address@hidden: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.

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

Attachments:
- issue-31.diff - 1.06 kB
  https://code.monotone.ca/p/monotone/issues/view/attachment/23/issue-31.diff


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


# By Thomas Keller, Aug 11, 2010:

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

# By Stephen Leake, Aug 15, 2008:

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

# By Markus Wanner, Feb  4, 2008:

Added unit test update_with_pending_modification, which checks for that bug.

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



--
Issue: https://code.monotone.ca/p/monotone/issues/31/