Re: [Monotone-devel] Understanding propagate

[Stephen Leake]

Phil Hannent <address@hidden> writes:

>     <meta http-equiv="content-type" content="text/html;
>     charset=ISO-8859-1">

Please don't post HTML to this mailing list.

>       I need help clarifying a workflow.
>       
>       I have three branches.
>       
>       elm.lynx
>       elm.lynx.beta
>       elm.lynx.production
>       
>       The first is mainline development and the subsequent ones beta and
>       production.

Ok.

>       Now whilst we are in beta we don't stop mainline development,
>       however a beta tester might report a bug which we want a fix for. 
>       A developer does that fix in the mainline elm.lynx 

Better to do the fix in elm.lynx.next_release, or even better in
elm.lynx.bug_<n>, branched from elm.lynx.beta.

>       I then have to review that and decide if its small enough and
>       self contained enough to pull into the beta branch for another
>       beta revision.

ok.

>       If I decided it is, then I pluck the revision in question. 

easier to propagate from elm.lynx.bug_<n>, or from elm.lynx.next_release.

>       Sometimes this has happened in the opposite direction where a beta
>       fix is plucked into mainline.

also easier via propagate.

>       However I am now finding that after one or two of these I get a
>       merge conflict when I do:
>       mtn prop elm.lynx elm.lynx.beta
>       
>       The files that were touched report a merge conflict.  I we have
>       never propagated from the beta to mainline, its always a one way
>       flow with plucking being the main means to move minor changes.
>       
>       Does the pluck create this problem 

Yes. Plucking is going behind monotone's back, which is why it's complaining.

>       and should I be propagating back from the beta into the
>       mainline?

Branches are cheap (not quite free, but really cheap), and propagating
between them is easy and safe. So use them often. You will get some
conflicts when people work on the same files in different branches; use
the 'mtn conflicts' commands to resolve them (or Emacs DVC).

At my work, each developer has one or more branches, and each release is
a branch, for small fixes. All major work is done on a developer branch;
developer branches are reused from release to release.

Everything is always merged to main eventually, and all releases are
branched from main.

In your case, for version 2, the flow would be:

do major work for version 2 in elm.lynx.developer_1, _2

approve work

propagate from elm.lynx.developer_1, _2 to elm.lynx

propagate from elm.lynx to elm.lynx.beta

find a bug

propagate from elm.lynx.beta to elm.lynx.beta.developer_1

fix bug in elm.lynx.beta.developer_1

approve fix 

propagate from elm.lynx.beta.developer_1 to elm.lynx.beta

approve beta release

propagate from elm.lynx.beta to elm.lynx.production_02

propagate from elm.lynx.beta to elm.lynx


You can reuse elm.lynx.beta, elm.lynx.developer_* for the next release.
However, if you have two betas in process at one time, you need
elm.lynx.beta_01, .beta_02, or something.

The only time you can't reuse a branch is if the work done on it was
deemed unsuccessful, so it can't be merged back to main. You could try
to disapprove all work on that branch, but it's easier to suspend it and
use another one.

-- 
-- Stephe