[MERGE] make 'push' default to parent branch

[John Arbash Meinel]

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

Colin D Bennett wrote:
| On Mon, 28 Jul 2008 12:47:35 +1000
| "Mark Hammond" <mhammond at skippinet.com.au> wrote:
|
|> 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.
|
| Since what Robert described was using a heavyweight checkout, it
| actually *was* a local branch of the remote branch.  Then he made
| another local branch off of the local copy (checkout) of the remote
| branch where he worked.
|
| Colin
|
|

A local heavy-weight checkout is basically defining that you want to
mirror the other branch. (And keep them in sync.) I actually use a
checkout of http://bazaar-vcs.org/bzr/bzr.dev so that I'm *not* tempted
to cheat and re-use the trunk branch to make my changes. It forces me to
use trunk as my default bzr, and not a hacked-up version.

*I'm* not a fan of 'bzr commit --local'. If only because we don't have a
good command for getting back-in-sync. bzr update moves all of your
local commits to being a merge, even if they could apply cleanly to the
master branch. With a locally committed heavy checkout, you also have
problems during 'bzr update', because you potentially can update the
working tree 2 times.  (Bring the tree to the tip of the local branch,
then bring both to the tip of the remote branch.)

My original model had you unbind, and then 'bzr bind' would bring the
branches back in sync as best it could. (If local would stack on remote,
or remote would stack on local cleanly it would do so, otherwise raise
Diverged.) We've moved away from that, mostly because we were hoping to
not need bind/unbind. I'm not sure anymore that it was the best choice.

Using checkouts, and then creating a local branch if you want local
commits might actually be a simpler model. You know it is offline
because you did 'bzr branch (& bzr switch?)' locally, and we have
perfectly good "cd checkout && bzr pull/merge ../local_branch" support
for bringing those local commits back into your checkout.

I *do* think it is recommended to keep a pristine copy of upstream. It
is certainly recommended for things like 'bzr send'.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiPTLUACgkQJdeBCYSNAAMBKQCeLrJanzWalQkqgxnL9SJz8Eye
ijgAn1Lzkc0R/nORAu8DCxxr4e5lsj/K
=0dNC
-----END PGP SIGNATURE-----