Phil Hannent writes:
>
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_, 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_, 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
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
