manage.... clones? or branches?

[Eric Siegerman]

Max Bowsher wrote:
> When you have a change in a client branch which needs to go back to
the
> main branch, you would do a cherrypick merge - the kind of merge which
> doesn't get recorded in the overall ancestry tree, because its a merge
> of a single change alone - not a change and all the changes which led
up
> to it.

Be aware that any history associated with the change *won't* be
propagated to the main branch -- a cherrypick merges content, but
not revision history.  So if the change consists of several
commits, each with a meaningful log message, all that will be
lost; the mainline will only record the commit that happens after
the merge.

That's less than ideal, but I don't know whether Mercurial or
git does any better.  (I'm under the vague impression that darcs
does, but at the cost of other limitations, which I believe have
been discussed before on this list.)


On Wed, 2010-12-22 at 17:38 +0100, Krilin Wantun wrote:
> * After committing a revision, it seems the button MERGE does
nothing, 
> and I need to push the PUSH button instead, is this correct?

It sounds as though, when you try to merge, you're still in the
branch where you've just committed the change.  That won't work.
"Merge" brings changes from another branch into the current one;
it doesn't send them *to* another one.  So you have to do the
merge from the destination branch.  ("Merge" and "pull" go in the
same direction; "push" goes the other way.)


> What if I 
> have parallel changes, MERGE should work then?

Meaning, what if each branch has revisions that the other one
doesn't?  Merge is still one-way, so you have to do this in
several steps:
 1. Get the CLIENTx branch up to date:
     a. merge from MAINLINE into CLIENTx
     b. resolve conflicts; fix bugs; commit

 2. Cherrypick your change from CLIENTx to MAINLINE:
     a. merge from CLIENTx to MAINLINE, specifying the revision
        (or range of revisions) you want
     b. resolve conflicts; fix bugs; commit

 3. Get the revision from (2b) into CLIENTx:
     a. merge from MAINLINE to CLIENTx (*not* a cherrypick)
     b. resolve conflicts; fix bugs; commit

Only one of steps (1) and (3) is strictly required; either of
them will bring the MAINLINE-only changes into CLIENTx.  Whether
you do (1) depends on which branch you want to use to resolve any
conflicts between the two sets of changes (including semantic
conflicts that bzr can't catch).

If you have indeed done (1), then (3) becomes optional.  It
likely won't change your files (unless unrelated new revisions
have been committed to MAINLINE since step (1a)), but it will
still propagate the revision created by (2b).  That doesn't have
to happen immediately -- it can wait till you have some more
MAINLINE changes to merge into CLIENTx -- but doing it now might
keep the revision history a bit cleaner, which helps you in the
future to understand just what happened when.

  - Eric