[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Re: How will policy branches work?
Date: Fri, 08 Feb 2008 13:22:46 +0100
User-agent: Mozilla-Thunderbird (X11/20080109)


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:

          (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:

             /   \
            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:

             /   \
            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:

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

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]