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

Sean Kelley sean.v.kelley at
Sun Jul 20 02:35:11 BST 2008

Thanks. This was extremely informative and useful information!


On Wed, Jul 16, 2008 at 3:38 PM, John Arbash Meinel
<john at> wrote:
> 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 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.
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla -
> OLMAn0NpIs7FcYag6u4KF1hfWWGOo1c2
> =En8F

More information about the bazaar mailing list