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

[Nicholas Allen]

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

I think you explained that extremely well! ;-)

This explanation should be on the wiki somewhere. It does a very good
job of explaining the checkout approach, why you would want to use it,
and what benefits it gives you. How the log shows you features instead
of the individual commits etc.

Nick

John Arbash Meinel wrote:
| 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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIgxBt1+i51gqqEGkRAqAhAJ0VTcwQE1LWPoO1v+40MrPlq1vxegCePCoN
JHPNcEhV7FMT+aQcEFyKO1M=
=0BVn
-----END PGP SIGNATURE-----