Re: bzr repository ready?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Date: Tue, 24 Nov 2009 03:06:33 +0900
> Cc: address@hidden
> 
> I'm reasonably satisfied that it would not be a waste of your time to
> review it at this point (and I'm looking forward to Eli's opinion, I'm
> hoping he'll find it useful).

It is very useful, thanks.  I have a few comments, mostly editorial,
and some questions:

   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?

   This first checkout may take many minutes.

It's unclear to what command this refers: none of them mentioned any
"checkouts".

   If there are other branches you’d like to mirror ...

Question: doesn't the local repository we just created include all the
branches anyway?  Didn't someone say that the repository allows
working off-line? if so, it should include all the branches in the
master repository, no?

   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:
   the source tree itself, which takes time to check out. Even more
   important, there will be no build products in the tree. make bootstrap
   takes an annoying amount of time. That’s why we recommend that for
   small changes you use a dedicated branch. Once you’ve bootstrapped the
   build, the update, build, and commit elements of the
   update-edit-build-test-commit cycle are all very fast.

This is confusing and looks like a merge of 2 different narratives.
Is ``dedicated branch'' what is later described as ``feature
branches'' or something else?  If the source tree is ``weighty'', then
why are the branches ``lightweight''?  Why is it important that there
will be no build products in the tree? etc. etc.  Please consider
rewriting this paragraph.

   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?  (Release branches will
need that, right?)

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

Thanks.