Re: bzr repository ready?

[Stephen J. Turnbull]

Thansk for the review, Eli!

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <address@hidden>

 >    If you are a committer, you will want to use a bzr+ssh URL instead:
 >    bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk.
 > 
 > Doesn't this URL require a savannah username somewhere in it?

Dunno.  Probably, but somebody who knows how Savannah works needs to
fix that up.  (Karl actually wrote that URL, but IIRC he's not a
Savannah user, either.  I bet he did what I would have done:
substitute "bzr+ssh" for "http" in the http: URL.)

 >    This first checkout may take many minutes.
 > 
 > It's unclear to what command this refers: none of them mentioned any
 > "checkouts".

Fixed on the wiki.

 >    If there are other branches you'd like to mirror ...
 > 
 > Question: doesn't the local repository we just created include all the
 > branches anyway?

Not as described in the wiki.  IIRC, there is currently no
straightforward way to mirror a whole bzr repository (except rsync
and/or tar), although the developers have made some noise about "doing
something".  When the wget+tar method gets straightened out, at least
that way will exist.

 > Didn't someone say that the repository allows working off-line?

Of course!

 > if so, it should include all the branches in the master repository, no?

Maybe.  It's not clear (eg, there's my discussion with Stefan about
where to put "sandbox" branches---they could go in the master
repository).

 >    Compared to CVS, these branches are lightweight --- it doesn't cost much
 >    to create them, as they're all sharing storage in the repository, and
 >    they can't bother anyone else. However, there is one "weighty"
 >    aspect: [etc, etc].

 > This is confusing and looks like a merge of 2 different narratives.

I'm not sure why you think that.  I've made some changes, but I'm not
real confident they address the confusion.

 > Is ``dedicated branch'' what is later described as ``feature
 > branches'' or something else?

Something else.  Rephrased to "branch dedicated to small changes".

 > If the source tree is ``weighty'', then why are the branches
 > ``lightweight''?

In Bazaar, the working tree and the branch metadata are basically
independent of each other; they can even reside on different hosts,
and branches can even exist without working trees.  Understanding this
is fundamental to designing efficient workflows for Bazaar.

However, in the context of a particular workflow, a collection of
trees, repositories, and branches will be associated with each other.

 > Why is it important that there will be no build products in the
 > tree? etc. etc.

That isn't obvious, even though I wrote "make bootstrap can take an
annoying amount of time"?  I've fiddled with it a bit, but I don't
know what to say.  If you still think it's confusing, I'll sleep on it
and try again in a day or so, or maybe Karl or a 3d party can do
something with it.

 >    Once you have completed the task, you'll want to send it
 >    upstream. You do this just as you would for a quick fix ...
 > 
 > What about branches in the master repository?  Unless I'm missing
 > something, the described workflows don't cover that.  What if I want
 > to have my branch available from the upstream?

What about them?  The workflows don't cover them, and won't, until
there's a policy permitting/regulating "sandbox" branches.  At this
point, only maintainers need to worry about them.  This is not a
document for maintainers (until Stefan, Yidong, or a release engineer
they appoint asks for it).

 > (Release branches will need that, right?)

Yes, but AIUI people who create release branches are not the target
audience of this document.

 > Finally, it looks like the TBDs near the end can be simply deleted
 > now, as what's before covers that turf already.

I thought about it, but there is too much history of bitching about
bzr performance (on address@hidden and on the 'net in general, I'm
not referring to the discussion here) to ignore: people *will* want
"efficient" ways to use Bazaar.  I decided to recommend stacked
branches (sort of like a lightweight checkout, but all commits are
local until you explicitly merge), which are very efficient at
creation, and only accumulate history after creation.  The advantage
over checkouts is that someone who goes ahead and edits the working
tree can commit locally and "bzr send", as described elsewhere in the
document.

I did delete the "Merging packages" and "Emacs releases" sections, as
I think they're out of scope.  Since they didn't contain any useful
content, we're losing nothing until someone who needs that knowledge
asks for it.