Bazaar workflow question...

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
=:->


On 2013-02-21 1:28, ckalisiak at attotech.com wrote:
> 
> 
> Hello all,
> 
> I have a question for the Bazaar community. We transitioned from
> VSS to Bazaar about 18 months ago, with fairly good success, but
> we're having some workflow issues, and I was hoping someone might
> have some suggestions.
> 
> Basically we have the following workflow: 1) A single master branch
> exists which contains all of our common code. This branch only acts
> as a container; development and releases are handled elsewhere. 2)
> For each planned product/release, the common code is branched, and 
> development for the product/release is done in the new branch. 3)
> At various points during the product/release branch's life cycle,
> merges between the common code and product/release branches take
> place, and revisions need to occasionally be shared between
> product/release branches themselves. 4) When a product releases,
> the final state of the product/release branch is merged into the
> common code, and the product/release branch is archived.
> 
> We haven't figured out the best way to keep branches synchronized.
> Both criss-cross merges and cherrypicking have occasionally
> resulted in silent errors being emitted by merge3, weave, and LCA.
> In one particular set of product/release branches, all three of the
> merge algorithms failed, but at least they failed differently, so
> the results could be compared. The silently emitted errors resulted
> in compiler errors, were fixed, and manual merges performed to
> confirm that no other errors were emitted.
> 
> In our workflow, what are the best practices to avoid criss-cross
> merges? Once a criss-cross has occurred, is there anything we
> should be doing besides comparing the results of multiple merge
> algorithms for correctness? How should we propagate "point fixes"
> from one branch to another, as cherrypicking and
> reverse-cherrypicking don't seem to be good options for us? Best
> case, cherrypicking results in merge conflicts, but worst case, 
> cherrypicking is where we've seen silent errors.
> Reverse-cherrypicking results in lost revisions at the final merge
> from the product/release branch to the common code.
> 
> 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"
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlErMjwACgkQJdeBCYSNAAOf8wCfWalNdoTn+96WEiUTQuTYlrpx
6yQAnApBbXzP4esc6TQT2iWM4ros37yw
=R7Wn
-----END PGP SIGNATURE-----