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

[Nuno Lucas]

On Feb 7, 2008 7:16 AM, Markus Schiltknecht <address@hidden> wrote:
> > By the way, I don't see as this is any different than what is already
> > done by a 3-way merge with user editings. It's not the original
> > revision either.
>
> Well, the difference is, with a 3-way merge, you are saying: my newly
> merged revision X is the successor of A and B - in all files.
>
> Here, you would need something like: revision X is the successor of A
> and B only for files in "libs/*". For files outside that restriction,
> there shouldn't be any preference (i.e. could still be A or B).

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?

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

> 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.

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.


Regards,
~Nuno Lucas

>
> Regards
>
> Markus
>
>