Bazaar workflow question...

[ckalisiak at attotech.com]

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.

Ok, now the other problem. What are best practices to avoid criss-cross
merges? 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).

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
    . 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?

Thanks,
Chris

--
Chris Kalisiak
Senior Embedded Systems Engineer
ATTO Technology, Inc.
Phone:  +1.716.691.1999 ext. 274
Fax +1.716.691.9353
"Powering the World's Networks & Storage"



From:	bazaar-request at lists.canonical.com
To:	bazaar at lists.canonical.com,
Date:	02/25/2013 07:00 AM
Subject:	bazaar Digest, Vol 96, Issue 9
Sent by:	bazaar-bounces at lists.canonical.com


From: John Arbash Meinel <john at arbash-meinel.com>
To: ckalisiak at attotech.com

As much as possible you want your changes to happen as a flow. Changes
in X get merged into Y get merged into Z.

When you find things in Y that need to be in X, the best way to do it
is to just cherry pick it, and then immediately merge them back (so
that you can deal with any specific fallout as the patch might need to
be tweaked to land properly in an earlier branch).

By keeping the merges flowing in one direction, you'll always be able
to do a simple 'bzr merge' for those changes.

John
=:->