Bazaar workflow question...

[Vincent Ladeuil]

>>>>> ckalisiak  <ckalisiak at attotech.com> writes:

    > John,

    > Thank you very much for your reply. It took me a few minutes to figure out
    > what you meant, but now I finally understand what bugfix branches are for.
    > I couldn't figure out why one would make a branch to release software
    > containing the bugfix and then not merge that bugfix branch anywhere. Now I
    > understand that you're distributing the bugfix source code itself from this
    > branch, and the branch just sits there, waiting to be merged into other
    > branches that need the bugfix.

I think you're after daggy-fix (http://wiki.monotone.ca/DaggyFixes/) and
probably 'bzr qlog' from the qbzr plugin to better understand what is
going on ("seeing is believing" ;)

    > Ok, now the other problem. What are best practices to avoid criss-cross
    > merges?

Basically, criss-cross merges happen when two branches merge each other
because they are at the same level (as far as DAGs are concerned).

If you keep branches deriving from each other instead (i.e. you merge
A into B but never B into A) you won't encounter criss-cross merges.
There are edge cases that you'll better understand by looking at the
graph ancestry with qlog when you run into them but most of the time you
can just safely ignore them.

    > Here's an example we ran into that resulted in a criss-cross:
    > 1) Common code base master is branch A.
    > 2) Development starts on a new project. Master branch A is branched, and
    > the new branch is called B. It will be used to release a product called
    > Widget B.
    > 3) While branch B is in development, a product based on B, called Widget C,
    > is starting development and will release after Widget B has released. Some
    > of the code changes made in the B and C branches need to be shared, but not
    > all (otherwise branch C would not have been created).

In this case, I would recommend the daggy fix workflow: landing the code
that is needed by both B and C into A (the branch they both derive
from). Or just in B and then regularly merge B into C.

More importantly, avoiding cherry-pick is generally a good thing if you
want to preserve accurate meta-data. Keep in mind that cherry-picking is
really the worst way to track "who did what when". Basically the dev
that does the cherry-pick is taking a set of changes in a branch
*without* telling bzr:

- who wrote this code (generally some other dev(s)),

- when the code was written (the cherry-pick will only tell you when it
  was committed in a single commit)

When all branches finally merge into your trunk, if you look at
annotations... you'll realize that bzr cannot tell anymore (reliably)
who was the real author of that cherry-pick.

    > One hypothesis that we've come up with to avoid a criss-cross is incredibly
    > tedious, but is the only way we can think of to keep the metadata safe:
    > 1) When the decision is made that branch C needs to be created, rename B to
    > (for sake of clarity) META.
    > 2) Branch META to B, and branch META to C.
    > 3) Any time B and C need to exchange code:
    >     . Make a bugfix branch from the start of META
    >     . Cherrypick to the bugfix branch

That's where you want to daggy fix.

Instead of committing in the branch where the fix has been found and
coded, you fix it in META and *then* you merge META into B and B into C.

The bzr-loom plugin (or the bzr-pipeline one) was targeting that kind
of workflow.

    >     . Merge the bugfix branch to META, B, and C
    > 4) When both B and C have released, merge both into META, then merge META
    > into the common code base master branch A.

    > Is there a simpler way to avoid a criss-cross merge and keep
    > branches B and C partly synchronized?

The rule is always the same, if you want to keep parallel branches
synchronized, merge them often.

And avoid cherry-picks as much as you can since they lack the
information bzr needs to make the merges conflict-free.

            Vincent