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

[Sean Kelley]

Thanks. This was extremely informative and useful information!

Sean

On Wed, Jul 16, 2008 at 3:38 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----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-----
>