[Monotone-devel] unexpected behavior from "merge_into_dir" + "propagate"

[Lapo Luchini]

I first created a sample sub-project:

sub% mtn au get_manifest_of
format_version "1"
dir ""
   file "sub_file"
content [71fa367aa2adf747bd05a43d516495cedcbf2b0b]

Then a sample main project:

main% mtn au get_manifest_of
format_version "1"
dir ""
   file "main_a"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]
   file "main_b"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]
   file "main_c"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]

Then I decided to "use" the sub-project in the main project
(as it is a useful library, don't you see? ;-) )

% mtn  merge_into_dir sub main libs
% mtn au get_manifest_of
format_version "1"
dir ""
dir "libs"
   file "libs/sub_file"
content [71fa367aa2adf747bd05a43d516495cedcbf2b0b]
   file "main_a"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]
   file "main_b"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]
   file "main_c"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]

Then I work a bit on the library, but I (incorrectly? probably... but
that's not the point) commit the changes in the main project itself.

% mtn au get_manifest_of
format_version "1"
dir ""
dir "libs"
   file "libs/sub_file"
content [8d905cdc9e9957824ab1c8f574733bf48a8ba46b]
   file "main_a"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]
   file "main_b"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]
   file "main_c"
content [1aebbf7953661ef55e989467cba7ee4b9875dfb7]

OK. So far, so good.
Of course, I know from experience, when the "sub" library will be
updated I will only need a nice "mtn propagate sub main" to get the
latest changes.
But as I committed changes in the main project.. I just said to myself:
what about propagating in the other direction? I never read about it, I
don't think it was supposed to work that way... but let's just try:
what I get is "no merge necessary; putting
ad521c121cd82b0255e132b7ab2cee3e64e3c681 in branch 'sub'"

DUH? How come the full revision of the 'main' branch can be a valid
revision for the 'sub' branch???
But indeed.. that's what happens:

sub% LANG=C mtn up
mtn: updating along branch 'sub'
mtn: selected update target ad521c121cd82b0255e132b7ab2cee3e64e3c681
mtn: adding
mtn: renaming  to libs
mtn: adding main_a
mtn: adding main_b
mtn: adding main_c
mtn: modifying libs/sub_file
mtn: updated to base revision ad521c121cd82b0255e132b7ab2cee3e64e3c681

...which is NOT AT ALL what I was expecting from that.
I either expected for it to "work as intended" i.e. importing the
changes on 'sub_file' upstream, the opposite of importing them
downstream with the "properly intended" propagation command OR denying
to do the operation "as it is not clear what you want to do in this
case"... having a "no need to merge" message was really unexpected.

Or am I wrong and there's a good reason it does it this way?
Was this behavior INTENDED or it is just an unintended side-effect of
code that was thought to be used in the reverse propagation order?

I mean: knowing mtn's internals I can certainly see WHY it worked this
way (i.e. the merge_into_dir stated a "I want to move this file a
subdir" fact)... but it's not very intuitive to me that it is "the right
thing the user is obviously expecting" anyway =)

    Lapo

PS: "mtn pluck" on the new main-revision did the correct thing... even
tough I don't like "pluck" very much, as it leaves no DAG-evidence of
what was done...