Re: bzr repository ready?

[Óscar Fuentes]

Stefan Monnier <address@hidden> writes:

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

I think you are partially wrong on this. With the scp you are cloning
(in the filesystem meaning) the directory where the GNU emacs repository
lives. This includes all branches, which means all VC metadata (history,
etc). I guess that the administrators used the --no-trees option when
they created the repository.

So you get all what you need including the files, it is just that they
are stored with the metadata and not visible/usable yet. Try this:

# Get a copy of the GNU repo:
$ scp -r bzr.sv.gnu.org:/srv/bzr/emacs
# Create a work branch:
$ cd emacs
$ bzr branch trunk work

The new branch `work' will contain all the files. The `pull' you do at
the end is unnecessary because you already have the most recent data
from the repository.

Your recipe is the right one for testing the CVS->bzr conversion (check
that all CVS branches and tags are there, etc). But for hacking, IMO scp
is highly discouraged, as there is no guarantee that you obtain the
repository on a consitent state and it may completely fail if the
administrators fuse the emacs repo into a global bzr repo for all GNU
projects. Besides, you usually are interested on one or two branches,
not on the whole repository.

So for hacking the best thing is to

# Initialize a shared repository:
$ bzr init-repo emacs-dev
$ cd emacs-dev
# Get the branch you are interested on:
$ bzr branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk
# Now you have everything you need on the `trunk' directory, including
# files ready to be edited. But you'll better leave it as a mirror of
# the branch on GNU and work elsewhere:
$ bzr branch trunk work
# Use `work` for hacking.

Note: the `bzr init-repo' assumes that you are working with the latest
stable bzr release (2.0) For previous versions, you maybe need

$ bzr init-repo --rich-root

or some other variant.

Really, now that 2.0 is out for some time, I see no reason for not
recommending it and deprecate previous versions. We are having
difficulties due to the multitude of supported workflows, and supporting
past bzr versions will only create more confussion.

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

Please note that the tarball method gives you the state of the project
at the time it was made, but of course you want to update your files
whenever necessary. For that you need read-only access to the
repository. If you can give http access to bzr.sv.gnu.org/srv/bzr/emacs,
forget about the tarballs and be done with that.

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

By default, you get a working tree (the files you work on), so "--trees"
is redundant. You have --no-tree (branch command) and --no-trees
(init-repo command) for explicitly requiring from bzr that it should not
create working trees (the actual files you edit on).

[snip]

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

Right.

[snip]

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

There is no such thing as "partially pushed changes". `push' is an
atomic operation that sends a series of commits (by default, those who
were not pushed yet) to some other branch. You can push changes whenever
you please, and pull changes likewise.

The use-case you mention is better solved with a feature branch. For
instance:

# Suppose you are working on my-feature branch/directory:
$ cd ..
$ bzr branch trunk bug-fix
$ cd bug-fix
...edit...
$ bzr commit -m "Fixed blah"
$ bzr push sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk
$ cd ../my-feature
# Incorporate your bug-fix into your work:
$ bzr merge --force ../bug-fix
# The --force option is in case you have uncommitted changes on your
# branch. It is advisable to not merge upon modified (edited &
# ucommitted) files, for not mixed the merged changes with your
# modifications.
# Commit the merged changes:
$ bzr commit file -m "Merged bug-fix"
... keep hacking on your feature ...

You could have a branch for that kind of work, instead of creating one
each time.

[snip]

-- 
Óscar