Re: bzr repository ready?

[David De La Harpe Golden <david@harpegolden.net>]

Thanks for the reply!

> In the recommended workflow in BzrForEmacsDevs, "trunk" is precisely a
> manually-maintained remote tracking branch. 

Right so.

> 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,

well, to the working tree of branch trunk, not to the branch as such?

> and these are *automatically* passed on to the upstream master
> when you commit.

So hybrid of D and non-D VCS.  I suppose that's why "bound branch" was 
"checkout", it was by an analogy to non-D VCS where a cvs commit
goes off to the remote server.  What happens when you commit "on" a
bound branch without network connectivity?  I guess it just fails,
since you're not really committing to the bound branch but rather
to the associated remote upstream branch?

> 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. 

Well, I suppose in the git world one just tends to avoid many committers 
in the first place (since given DVCS  there's no actual need for much 
shared access beyond perhaps some redundancy), and the occasional 
conflict isn't the end of the world.  Maybe it's easier to rewrite 
history in git though, I know nothing of bzr (though I did just find bzr 
rebase)