Re: bzr repository ready?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>  . The description starts with "bzr init-repo" followed by "bzr
>    branch", but in fact all the discussions on the subject I saw till
>    now recommend to "scp -r" instead.  It is unclear whether any of
>    the first commands should be modified, replaced, or removed if the
>    "scp -r" method is used.

Yes, the "scp -r" does the "init-repo" plus fetches the branches.
What it doesn't do is "check out" the branches, i.e. populate the
directories with the files of the branches.  So you need something like:

  scp -r bzr.sv.gnu.org:/srv/bzr/emacs .
  cd emacs/trunk; bzr checkout
  bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk

IIUC scp only works for non-anonymous access, so we'll want to place
a tarball somewhere for download so the scp will be replaced by
"wget+untar".

>    Also, the above doc.bazaar URL uses the --trees switch to init-repo.
>    What is its significance, and do we need to use it?

IIRC it means that when you do "bzr branch" (aka "bzr clone") you'll get
a branch complete with its files, whereas otherwise you'd only get
a branch without its files (i.e. it would require a separate "bzr
checkout" as I did above in order to get the files).

>    Is this structure imposed by Bazaar or known conveniences, or is
>    it just a suggestion, and the directories can be anywhere?

Just a suggestion.  Emacs's own repository uses "trunk" for the main
line of development, so it makes sense to use the same name, but it
doesn't have to be the case either.

>  . The considerations for starting a "task branch" as opposed to a
>    lightweight branch are not clear.  The text talks about "multiple
>    commits and rounds of feedback", but keeps silent about what does
>    this "feedback" mean in practice.  More details are needed to make
>    the "lightweight vs task branch" decision in practice.

For any kind of development, I strongly discourage lightweight branches,
unless you have very fast and constant access to the base repository
(i.e. most likely not the case if the base repository is the Emacs
repository).

>  . The description of pushing local changes upstream say nothing about
>    the ChangeLog files.  IIUC, unless I do something special, all my
>    local log entries get to the upstream log files verbatim, and
>    therefore (a) will be out of time-line (i.e. dates will not
>    increase monotonically anymore), and (b) will include entries about
>    intermediate changes we generally didn't want to see up until now,
>    such as changes in functions that were subsequently deleted, or
>    changes in functions that didn't exist on the trunk before local
>    changes were pushed.  Unless there's some magic here that does TRT,
>    I think we need instructions for this area.

There's no magic.  Since we will still use the ChangeLog file, that file
will need to be written (or at least fixed up) at the time you push to
upstream).

>  . The text says to update the mirror only _after_ pushing the local
>    changes from the task branch and deleting that branch.  Is it not
>    possible or advisable to update the mirror with partially pushed
>    changes, while the task branch still exists?  (Use-case: while
>    working on a new feature, I discover a bug in the existing code,
>    and want to fix it without waiting for my final push.)

No idea.

>  . It's unclear whether building inside the mirror branch tree is okay
>    or not.  For that matter, it's unclear whether the ``thing''
>    created by "bzr branch" is just a simple directory tree, like the
>    one created by "cvs checkout" (in which case one can build from
>    within that tree), or something with more complex metadata, which
>    makes building and editing in it undesirable.

It's just like a cvs checkout in this respect.

> Yes, but it just says "1.17 or higher", to support some unnamed
> features needed for Emacs.  Current versions of Bazaar are 2.0.2 and
> 2.1.0b1.  It would be good to have recommendations for the best
> version since 1.17.

I think "1.17 or higher" is about as good as it gets.  More recent
versions will give you more recent code with new features and new bugs,
of course, but I don't think there's any preferred version.  Of course
if you have to download one, you might as well download the latest
stable version.


        Stefan