[Monotone-devel] Re: branches

[graydon hoare]

Derek Scherger wrote:

> Is it possible to have something like a common branch and a platform 
> specific branch (i.e. like net.venge.monotone and 
> net.venge.monotone.win32) where files have incompatible changes on the 
> two branches?

yes, it is definitely possible to do this. that is the purpose of branching.

> It seems that as soon as a file changes in a conflicting way that 
> propagate simply fails (during the "phase #3" checks in diff_patch.cc). 

it doesn't exactly fail; it simply asks the user to intervene and 
resolve the conflict. a special case of this is when there are 
conflicting tree-layout changes (rather than intra-file changes); 
currently we don't have an "ask user for help" hook for that. we should. 
that's a missing feature.

> Supposing that I'd like to be able to overhaul some particular file on a 
> development branch while maintaining a stable branch, it seems that this 
> is a fairly likely case. Another case might be that these branches may 
> never be merged and that the incompatible differences are the point for 
> the branches.

sure. you're under no obligation to propagate changes between branches.

> It's very possible that I'm missing something here... ;)

if you'll forgive my guessing, I think you might have confused "parallel 
edits" and "conflicting edits". suppose, in your example, you have some 
"platform branches" with platform-specific changes to a file foo.c. if 
some "common branch" makes a change to foo.c, it is a parallel change. 
that is, foo.c looks like this:


  --- common ---\------ common edit ----- common foo.c
                 \
                  \---- platform edit ---- platform foo.c

you can propagate from common to platform. this will do a 3-way merge 
between the common and platform foo.c files, using the branchpoint as 
ancestor, and place the result in the platform file. you could use this 
for example to move bugfixes around. it is *very likely* that the 
changes will be mergable. most changes are. that's the fundamental 
insight CVS made: most changes do not conflict, even within the same file.

when there is a conflict -- meaning both changes affect the same lines 
in the same file in an incompatible way -- only then does the user need 
to intervene. but the intervention is usually quite easy. install xxdiff 
or ediff, and it is simply a matter of clicking on a couple hunks and 
possibly editing a couple of lines.

> The following comment about propagate in commands.cc has me wondering 
> what power is lost and what flexibility is gained.
>
>   this is a special merge operator, but very useful for people maintaining
>   "slightly disparate but related" trees. it does a one-way merge; less
>   powerful than putting things in the same branch and also more flexible.

consider that "monotone propagate" moves one set of changes between one 
source and one destination branch. you could organize your work so that 
each user -- or even each change! -- goes in a separate branch, and 
users who want to integrate or exchange work need to explicitly ask for 
a propagate from "someone else's branch" to "their own branch". that is 
a bit like how arch works. you have to run "propagate" quite often, but 
it's very flexible: you're saying "give me exactly these changes, and no 
others".

in comparison, consider that "monotone merge" collects "all" the 
parallel changes made to a given branch and tries to merge them into a 
single head. this could be dozens of changes made by many independent 
people, for different reasons. merge is a powerful command. it's also a 
blunt and inflexible command. you aren't picking and choosing amongst 
incoming changes, you're saying "please try to form a consensus head". 
that is a bit more like how CVS works (with the communication order 
inverted: commit before merge rather than merge before commit).

does this clarify matters?

-graydon