[MERGE] make 'push' default to parent branch

[Robert Collins]

On Mon, 2008-07-28 at 09:53 +1000, Mark Hammond wrote:
> Robert Collins:
> > 
> > On Sun, 2008-07-27 at 14:32 -0600, Scott Scriven wrote:
> > >
> > > The parent URL may be the wrong place to push, but it may also be the
> > > correct place (especially if the user has migrated from a centralized
> > > system).
> > 
> > I'm curious, if they've just migrated from a centralised system, why
> > the user wouldn't use bzr's centralised workflow - 'checkout', 'update'
> > and 'commit' ?
> 
> Because then they wouldn't see how wonderful bzr is compared to svn :)  The
> workflows bzr calls "centralized with local commits" and "Decentralized with
> shared mainline" look like a big step forward from SVN.  For the vast
> majority of projects I work on that are currently SVN, the latter of those 2
> models are exactly what would be used, pushing and pulling the exact same
> remote branch.
> 
> FWIW, as a fairly recent SVN refugee and past light user of hg, my initial
> reaction is that "push" should indeed default to the parent branch - but I'm
> not yet versed enough with bzr to know if I would still agree with that in a
> few months...

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.

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

(I rarely do case 1))

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

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)

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080728/39afc482/attachment.pgp