Re: bzr repository ready?

[Stephen J. Turnbull]

Jason Earl writes:
 > "Stephen J. Turnbull" <address@hidden> writes:
 > 
 > > But Bazaar branches *cannot* at present be colocated; they *cannot*
 > > share a working tree.  That means that if you do a "bzr branch" for a
 > > one-line change, you have to do a "make bootstrap" to test.
 > > EEEEEEeeeeeewwwwww.
 > 
 > That's not entirely true.  I keep a "workspace" checkout in my
 > repository and then "bzr switch" between the branches that I am working
 > on.

Sure, what I wrote isn't 100% accurate.  But it's close enough, and
reasonably intelligible to novices (at least I tried to make it so).

So please, as Eli implicitly requested, let's talk one workflow at a
time.  I'm fine if you want to change to a different workflow which is
admittedly better, but what you just wrote is not an explanation of a
different workflow, or even an admission that you *are* talking about
a different workflow.  It's merely a laundry list of new vocabulary
for novices to learn, with no definitions.  And Eli *did* ask about
the workflow I wrote about.  In more detail:

In git the workflow in question is

1.  Observe an issue.  Plan a design and task to deal with it.
2.  "git checkout -b issue-oriented-task"    # create and checkout new branch
3.  Hack away.
4.  "git commit -a -m 'Here is a problem and how I solved it.'"
5.  "make"
6.  Run tests.
7.  If problems, goto 4.
8.  "git checkout master; git merge issue-oriented-task; git push"

These git operations are very fast and transparent; this is a winning
workflow.  In bzr, the same workflow is implemented

1.  Observe an issue.  Plan a design and task to deal with it.
2.  "bzr branch trunk issue-oriented-task"
3.  "cd issue-oriented-task"
4.  Hack away.
5.  "bzr commit -m 'Here is a problem and how I solved it.'"
6.  Prepare to test: "make bootstrap"
7.  Run tests.
8.  If problems, goto 4.
9.  "cd ../trunk; bzr merge issue-oriented-task; bzr commit; bzr push"

This workflow sucks because steps 2 and 6 are slow, but people more
familiar with git than bzr are likely to remember it, adopt it
themselves (and be frustrated and switch back to git), and recommend
it to novices (who will also experience frustration).

Now you're suggesting an alternative which is just about as efficient
as the git workflow.  *But* there's an important difference.  Both
workflows described above depend only on the existence of a mirror
branch; otherwise they are standalone, they work just as well for a
single contribution as for a regular contributor.  The workflow you
are suggesting, though, has some components that look like the above,
and others that involve preexisting context (several branches, for
example) and new commands which are actually old commands with new
names (bzr switch, at least).  Somebody needs to explain all that (and
it's not going to be me, unless Tim O is about to offer me a book
contract ;-).