Re: bzr repository ready?

[Stephen J. Turnbull]

David De La Harpe Golden writes:

 > That's the thing - Are you skipping a step here? At least, you've
 > got no _manifest_ local mirror of UB.

You don't have one in git, either, only a ref labelled with the
remotes/ prefix. 

 > Why aren't I implicitly or explicitly making a local
 > remote-tracking branch RB mirroring UB, then local branch LB ?

In the recommended workflow in BzrForEmacsDevs, "trunk" is precisely a
manually-maintained remote tracking branch.  bzr will not do this for
you, you have to do it yourself.

 > *** Except for the bit where someone ...commits local changes on it... 
 > Wait, what?

You don't commit any local changes, because you didn't make any in
that branch.  You *merge* local changes to it from your working
branch, and these are *automatically* passed on to the upstream master
when you commit.

 > Fortunately, I'm not an upstream committer, I'll presumably be sending 
 > or asking upstream committers to pick stuff from my public tree, but 
 > still, I'm clearly missing something.

No, actually you're not missing anything.  At least, you've already
noticed that bzr is not git, and that's all that's going on here.

 > and then commit
 > 
 >        bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
 >
 > which automatically pushes all your new commits to the upstream master, 
 > because the mirror is set up as bound branch.
 > """
 > 
 > *** why is this happening on branch trunk

Because branch trunk is bound to the upstream master, it is not
possible to commit unless the implied push is a fast-forward.  This is
exactly what you want; if the commit fails, you simply do "bzr pull
--overwrite" (or "bzr revert; bzr pull", I forget which I wrote in
BzrForEmacsDevs), and then do the "merge-to-SOMETASK, maybe fix merge
conflicts, merge-back-to-trunk" dance again.

 > and not a branch my-trunk branched from trunk?

Because it's pointless to do that.  The race condition in using
my-trunk (not bound to upstream master) means that you can succeed in
committing the merge, but fail the push.  So you rm -rf my-trunk[1],
and start over, with "bzr branch trunk my-trunk".  Yuck.  If my-trunk
*is* bound to upstream master, things work nicely (losing the race is
fail-safe), but branch "trunk" is redundant.


Footnotes: 
[1]  In principle.  It's actually feasible to rollback history in this
case, but there's no way I'm going to describe that in a document for
newbies because the conditions for safety require a lot of
understanding of bzr theory of ops.