Re: [Monotone-devel] Re: How will policy branches work?

[Markus Schiltknecht]

Hi,

Nuno Lucas wrote:
> I see the problem now.
> Seems like the simple way of solving it may be by introducing helper
> revisions. But that could clutter the repository with no apparent
> gain, aside more history.
>
> OTOH, I somehow missed the path restriction option on "mtn pluck".
> Maybe it wasn't there the first time it was introduced?

Uh.. looks like the manual also doesn't know, yet.

> Haven't tried it yet, but it will always be better than using an
> external diff/patch cycle.

Not much, IMO, because with regard to history, it looks almost the same. 
The only benefit pluck gives to diff/patch, is properly tracking renames.

However, unlike with propagate, you have to track manually what you've 
merged and what not. As this is some form of "cherry picking", that's 
probably what you want in that case.

> > I'm rather thinking, that changes to such modules should be committed
> > separately, anyway. Thus, they can separately be merged by the people
> > who know how to merge them. Those who don't shouldn't be forced to do
> > the merge, yes. They don't have to. But they also shouldn't be forced to
> > cope with partly merged revisions.
>
> The problem is not with separate commits, but with commits inter
> spaced with other commits to other files on the workspace, meaning
> there isn't a linear serie of changesets only touching those files.

Well, as long as no single commit spans several modules, you should 
probably use separate branches per module anyway.

Additionally, you can use explicit_merge to some extent, to only do the 
merges you actually want to do. However, you are right in that that's 
tedious, because monotone forces the "older" merge to be done first. An 
example, to make sure we speak about the same things:


                    A
          (touching files in modules:
                 foo and bar)

            /                    \
           /                      \

         B                         C
     (touching                 (touching
        bar)                      bar)

         |                         |
         |                         |
         |                         |

         D                         E
     (touching                  (touching
        foo)                       foo)



In such a case, the developers who are working on module foo cannot 
merge revisions D and E, without also having to merge B and C. My 
argument was, that the developers of module bar can explicit_merge 
revisions B and C (instead of D and E, having to do all of the merge) 
and then let the foo developers merge their changes.

But it's a little bit more complicated, because after the foo developers 
have explicitly merged C and D, we have three heads:

               A
             /   \
            B     C
            |\   /|
            D  F  E

If the developers of module foo try to merge D and E, they will have to 
redo the merge of B and C. Instead, they should first merge D and F, 
then E and F, both of which should be clean merges, resulting in two 
heads, G and H:

               A
             /   \
            B     C
            |\   /|
            D  F  E
             \/ \/
             G   H

Only after that, they can do "their" merging, by merging G and H, 
without having to bother about module bar.

> Probably this will be solved when monotone gets a proper "cherry pick"
> system. It would then be possible to "pluck" some group of revisions
> (that could be restricted by path) and retain history.

I'm not exactly sure what you have in mind for being a "proper cherry 
pick" thing.

However, being able to do path restricted merges would result in 
different DAGs per path restriction, no? Let's check our example and 
assume both groups of developers do their merges, restricted to paths. 
We would end up with:


                A
              /   \
             B     C
             |\   /|
             D  I  E
              \   /
                K


Revisions I and K were merged with a path restriction to module bar and 
foo, respectively. So, overall, we now have four heads: I (for files in 
module bar), K (for files in module foo) and D and E (for all other files).

I've drawn I with ancestors B and C, because those are the "heads" for 
the path restriction in question. This gives us the advantage of getting 
a full revision, instead of a path restricted one.

Of course - as above - merging them in the right order gives you all 
clean merges and a single head. (This would maybe speak for letting 
monotone merge everything it can merge cleanly.) However, merging in 
presence of path restricted revisions doesn't exactly sound trivial.

Assuming you cannot merge two restricted revisions, but only a full 
revision with a restricted one, the right order here would be:

 * merge D+I to L, and E+I to M
 * merge M+L to N
 * merge K+N to O

Not to mention, that the user interface for such "path restricted 
revisions" would become quite complicated and confusing, I think. Or how 
do you plan to tell the user he cannot checkout K? Or why he cannot 
update from D to K.

Or if you allow that update - for the restricted files merged by K - 
what should a commit on that workspace look like? Yet another path 
restricted revision?

I think this would be doable, but is it worth the effort? And doesn't it 
confuse users more than it helps them?

Regards

Markus