Re: bzr repository ready?

[Stephen J. Turnbull]

David De La Harpe Golden writes:

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

Uhm ... you're comparing with git merge, which commits-unless-conflict?  
That's right, a "bzr merge" is entirely VC-data-to-working tree (you
can do it from a branch or a specially-formatted merge directive file)
operation, and doesn't automatically commit.

My point was that the commit in the suggested workflow is based on VCS
data, and therefore reversible and recoverable.  It's not based on
user changes, which would be irrecoverable if you did something like
"bzr pull --overwrite".

The whole suggested workflow is designed with two principles in mind:

1.  A user shall not be asked to choose between committing the content
    of his workspace and getting an update from upstream.
2.  The default view presented by "bzr log" shall be the list of the
    user's commits in his workspace, and the list of contributions
    (each of which may contain a long sequence of commits) in the
    upstream master and its mirrors.

I don't really care, but no. 2 is a feature that people who like
Bazaar love until the fur comes off.

Caveat: in the above, I'm speaking for myself, not for Karl.

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

Yes.  And that analogy is even closer with "checkout --lightweight",
which is why the terminology (and the default) is moving in that
direction.

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

Yes.  If you know you're disconnected, you can do "bzr commit
--local".  As Stefan mentioned in passing, there are some issues with
this.  I don't know whether it's in the implementation of Bazaar or in
the implementation of Stefan ;-), but if it's the latter, I'm sure
you're aware that that implementation is quite advanced and robust, so
this feature is hard to use. :-)

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

That's false.  Decentralized project workflows like Emacs's do need
it.  The more centralized single-maintainer and gatewayed project
architectures (a la the well-known punk code artists "Linus and His
Lieutenants") don't, of course, but distributed VCS supports a wide
variety of workflows.

Be that as it may, the current proposal AIUI is to emulate the current
CVS-based *project-level* workflow as closely as possible.
Individuals with experience with dVCS are welcome to vary their own
workflows as they please, but as you will observe in this thread rms
and Eli Z are (to a greater or lesser extent personally) concerned
with workflow disruption, and Stefan has explicitly indicated that at
first minimizing disruption is a goal (sine qua non?)

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

Much easier!  Don't rewrite history in Bazaar.  It's very limited,
painful, dangerous[1], and worst of all :-) you will be treated as a
pariah by many in the Bazaar community.

Footnotes: 
[1]  It's non-trivial to recover an obsoleted head.  No reflogs, no
documentation of the commands needed to find heads.