Bzr workflow for developers struggling with the DVCS "Pull" model

[John Arbash Meinel]

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

Sean Kelley wrote:

...

| Can anyone share with me how Bzr might differ from the HG/GIT "pull"
| model in workflows?  Is there more flexibility such that perhaps I
| should consider switching from HG to Bzr?
|
| Thanks,
|
| Sean
|
|

I believe I follow what you are saying. And I think the answer is the
'checkout' model.

Specifically, you have a branch which you consider Trunk/Mainline/etc.
This is generally placed in a location that multiple people are able to
commit to it.

Developers then do:

~  bzr init-repo --trees project
~  cd project
~  bzr co bzr+ssh://host/project/trunk

To create a local "checkout" of the trunk branch.

At this point, any time that they do "bzr commit" in that branch, it
will first put the commit in bzr+ssh://host/project/trunk. If that
branch has been modified since they last time they did 'bzr update' (or
bzr checkout), the commit action will fail.

In this way, it is fairly similar to a svn/cvs style 'checkout'. Except
it has a few bonuses, like having all of the history information
locally, so diff/status/etc are fast.

It also can support offline commits, but my recommendation there is
different.

Specifically, after a developer has the trunk checkout, I would
recommend that the create their own local branch to do the work.

~  bzr branch trunk work

or

~  bzr branch trunk featureX

At that point, they do most of their development in work/featureX rather
than in trunk. The idea is that they can do whatever they want, commit
as they go, etc. And when things are ready, *then* they can be merged
into the trunk.

This is probably similar to how you were working with pushmerge (if I
understand the functionality correctly), with a caveat about that final
'push'.

Specifically, rather than pushing your feature branch and making it the
official trunk branch, I would recommend:

~  cd trunk
~  bzr merge [--pull] ../featureX
~  [bzr commit]

At that point, the changes will be in the trunk branch for everyone to
get. I personally would recommend plain "bzr merge; bzr commit". But I'm
trying to understand your issue with "lots of messy merges in your history".

If you want to do a 'pull if possible, else merge' then you can use 'bzr
merge --pull'. I don't prefer that method, but some projects prefer it.

The reason I prefer to 'bzr merge && bzr commit' in the trunk branch, is
because it gives a clear history of what has landed in trunk. For
example, if you grab bzr.dev and do:

~  bzr log --short -r -10..-1

You can see the last 10 *features* that landed in trunk. Compare that
with 'bzr log --long --limit 10', which goes into a lot of detail about
the changes I did to implement Weave merge (revno 3543), but can't even
describe all of those changes (it took 19 commits to implement the feature).

IMO, 'bzr log --short' combined with merging into Trunk is a great way
to see the overview of what has been going on. And while each one of
those commits is a merge, I find the *details* to be much more clutter
than the clear "Fix bug XXX", "implement branch stacking", etc.


Now, you can simulate checkouts with appropriate care and "commit +
push". The difficulty is when there is a race (someone commits before
you do), and then you have to uncommit, pull, commit push. (rather than
having the commit fail, so you just update and commit again.)


The other nice thing about trunk checkouts, is that it can scale the
complexity based on how much the developer understands. Often, a simple
checkout, update, commit is enough for a developer. They don't need
offline commits or feature branches, etc. Once they get to the point
that they want those, though, they can just start using it.

John
=:->

PS> I would point out one bit of Terminology that is different here. In
hg/git they call everything a 'repository'. In Bazaar, we distinguish
pieces. A 'repository' is where the data is stored, it may be local, it
may be remote, it may be co-located with a working tree and branch, or
they may be separate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh+XE8ACgkQJdeBCYSNAAPnuQCeNBPRAynyggulJfNHn0Zgeom6
OLMAn0NpIs7FcYag6u4KF1hfWWGOo1c2
=En8F
-----END PGP SIGNATURE-----