[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: branches
From: |
graydon hoare |
Subject: |
[Monotone-devel] Re: branches |
Date: |
Mon, 03 May 2004 12:39:14 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040208) |
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
- [Monotone-devel] branches, Derek Scherger, 2004/05/02
- [Monotone-devel] Re: branches,
graydon hoare <=
- [Monotone-devel] Re: branches, Derek Scherger, 2004/05/03
- [Monotone-devel] Re: branches, graydon hoare, 2004/05/03
- Re: [Monotone-devel] Re: branches, Christof Petig, 2004/05/04
- [Monotone-devel] cooperative/parallel/resumed merging (was Re: branches), Christof Petig, 2004/05/11
- Re: [Monotone-devel] cooperative/parallel/resumed merging (was Re: branches), Patrick Mauritz, 2004/05/11
- [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches), graydon hoare, 2004/05/13
- Re: [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches), Joel Rosdahl, 2004/05/13