[Monotone-commits-diffs] net.venge.monotone: 28b7ef3c32aeb81e1f5549941cb62e317c81ea4f

[code]

revision:            28b7ef3c32aeb81e1f5549941cb62e317c81ea4f
date:                2012-09-03T07:32:46
author:              address@hidden
branch:              net.venge.monotone
changelog:
* doc/monotone.texi (dropped_modified conflict): improve

manifest:
format_version "1"

new_manifest [86bf371523dd267abc5ae29f248109b8b7e0d417]

old_revision [54bbe85d3580d04a212337c11f075a2b96dabefb]

patch "doc/monotone.texi"
 from [d32d1c3dd0573dd7a537bbf972a607d7390777b1]
   to [f6d90f8b4bd471610779544609a14675c1cd55af]
============================================================
--- doc/monotone.texi	d32d1c3dd0573dd7a537bbf972a607d7390777b1
+++ doc/monotone.texi	f6d90f8b4bd471610779544609a14675c1cd55af
@@ -3509,11 +3509,11 @@ @subheading Dropped/Modified file Confli
 processed when @command{--resolve-conflicts} is specified; the user must
 delete such files when they are no longer needed.
 
-The attribute is useful in the case
-where the conflict will occur again in the future, for example when a
-file that is maintained in an upstream branch is not needed, and
-therefore dropped, in a local branch. The user only needs to specify
-the conflict resolution once, via the attribute.
+The attribute is useful in the case where the conflict will occur
+again in the future, for example when a file that is maintained in an
+upstream branch is not needed, and therefore dropped, in a local
+branch. The user only needs to specify the conflict resolution once,
+via the attribute.
 
 Because of the @emph{die-die-die} policy, monotone internally must
 first drop the modified file, and then add a new file with the same
@@ -3523,11 +3523,15 @@ @subheading Dropped/Modified file Confli
 still there; the user can see it by starting @command{mtn log} again
 for the same file but in the parent of the merge.
 
+Note that we don't need a @command{keep} value for the
address@hidden:resolve_conflict} attribute; if the local branch keeps a
+file that the upstream branch drops, the first keep resolution will
+break history, and the conflict will not occur again.
+
 A special case occurs when the user re-adds the file after dropping
 it, then attempts to merge. In this case, the possible resolutions are
 to keep the re-added version, or keep a user modified version,
-replacing the re-added version (drop is
-not a valid resolution).
+replacing the re-added version (drop is not a valid resolution).
 
 There is no such thing as a dropped/modified directory; if the
 directory is empty, the only possible change is rename, which is