Shawn Samuel <address@hidden> writes:
> Alice has consolidated the functionality from File A into File B
> (which already existed, so there's no rename)
[...]
> The change I made gets silently squashed, without warning, and Alice
> has no reason to suspect that she needs to update File B.
Is there any relationship between File A and File B? Your "no rename"
comment above suggests that there's not, other than the transfer of
some code from A to B.
If Alice wishes to track changes to a file but she doesn't want that
file to be present in her branch, she has conflicting goals.
You're looking for a merge conflict to serve as a kind of
communication means, even though in this case Alice would most likely
just kill File A again and merge A's deltas into B. That sounds like
the wrong way to go. Alice is being punished for copy-and-paste reuse.
In order to have monotone participate in this communication and assist
with the change flow, Alice should whittle A down in her branch to the
parts she wishes to keep, and refer to that slimmed-down A from B. As
changes appear in A, she can merge interactively, accepting only the
changes to the parts she's interested in using.
> It seems to me that a file change to a deleted file should create a
> merge conflict that needs to be resolved because there's clearly new
> information that needs to be accounted for.
I think this is a symptom of the "deleted stays deleted" rule.
Related question: In light of this rule, is there any way to "revive"
a file in a later revision, if one realizes that a given branch should
include the deleted file again?