[MERGE] make 'push' default to parent branch

[Russel Winder]

Mark,

On Mon, 2008-07-28 at 12:47 +1000, Mark Hammond wrote:
> Following up more for my own understanding than anything else...
> 
> Robert wrote [but quoting out of order]:
> 
> > So for the use cases given, here is how I do the same thing:
> > case 1) work directly on a remote branch I can write to
> > bzr checkout lp:foo
> > hack
> > commit --local as needed
> > repeat
> > commit
> 
> That's interesting - I should play with that a little more.  My brief
> reading left me with a concern I may accidently forget '--local' in some
> cases, so this would be a good option if branching was not.  I probably need
> to actually suck-it-and-see.

Personally I used to do the above a lot, but I stopped doing it
completely in favour of having separate branches and using push.  I
guess though that this is an inversion of master and slave.  I work on
the principal that my branch is the master and that the pushed to branch
is being made into a mirror of my branch. 

> > case 2) work on a local branch for something I can write to
> > bzr checkout lp:foo trunk
> > bzr branch trunk local
> > cd local
> > hack & commit
> > repeat
> > cd trunk
> > bzr update
> > bzr merge ../local
> > commit
> 
> Yeah, that does make a lot of sense and branching a checkout is something I
> wouldn't have considered!  It takes a while to get your head around how
> flexible things really are.

I am ambivalent about this one, in the "Why bother?" sense.  This is
very much a model in the SVK mold and it gets irritating.  I guess
checkout is useful if there must be a mirror locally, but otherwise it
gets irritating if there is any potential for disconnected working.

On the other hand I think it is an easier model to work with that 1.
The whole unbind/bind/"commit --local" thing required of 1 when used in
a potentially disconnected context just became a right pain for me. 

And, the fact that Tim told me I was doing things wrong :-)

For the Groovy project I don't bother with the checkout but have a
branch to act as mirror (this may have been an error though I am open to
suggestion) of the Subversion mainline.  Then in a shared repository I
can branch this for doing various bits and pieces.    Whether to use
push or merge is not yet something I have completely decided on.  It is
a master/slave question I guess.

> You started with:
> 
> > I have an observation to make here. I *very* rarely use push to
> > integrate work.
> > 
> > I use push to maintain an exact mirror of a branch.
> 
> Both your workflows above involved working with checkouts, which is probably
> where my misconception starts.  However, it seems some bzr docs
> (http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html at least)
> recommends making a local branch of the remote repository, then making
> another local branch to do the work.
> 
> Am I correct in saying that if (and possibly only if!) you followed that
> HACKING workflow, you *do* need to use "push" to integrate changes, and that
> for many smaller projects, it is likely you will want to push to the parent
> branch?  (Which isn't trying to make a case to change the default behaviour)
>  
> > I think the key thing driving this difference is that bzr logs
> > in /topological order/. Neither git nor hg log in topological order.
> > (And they don't log in the same order as each other). The behaviour of
> > log alters what people look for in other commands to a surprising
> > degree. I'm not 100% sure bzr has the best possible answer to log, but
> > I
> > am sure its better than answers git and hg have.
> > 
> > (git logs in topologically-constrained date order, which means you are
> > not seeing what commits were done together, rather the concurrent
> > activity in N branches that eventually got merged. This makes log very
> > hard to follow).
> > 
> > (hg logs in 'insertion-into-repository' order, which is topologically
> > constrained but unstable between developers of concurrent branches)
> 
> Interesting...

Very much so.  Bazaar needs to positively market its differentiators and
USPs.   There are many people out there who believe the hype (FUD?) that
Git and Mercurial are the market leaders and Bazaar is a distant third.

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077