Re: bzr repository ready?

[Karl Fogel <kfogel@red-bean.com>]

Richard Stallman <rms@gnu.org> writes:
>     > They are not equivalent.  The ChangeLog files are included in the
>     > checkout, so you can read them even when you are offline (which is
>     > nearly all the time, for me).  `bzr log' requires contact with the
>     > repository.
>
>     Yes, but the repository is local too!
>
> Maybe I misunderstood something.  I thought the idea was to make
> a local checkout from a remote repository.  Are you saying people
> should always copy the whole repository first?

Because I don't know how experienced you are with Bazaar yet, I don't
know if you're using the word "repository" in the CVS sense or in the
Bazaar sense, above.  The two meanings are very different.

What I meant when I said "the repository is local too" is that history
is local, and that therefore you can read it while offline (thus you can
generate ChangeLog information while offline).  By the way, I agree that
we should not switch our ChangeLog practices when we switch version
control systems -- the "change one variable at a time" rule is good.  So
this is just informational; I'm not advocating that we stop keeping
ChangeLog files the moment we switch to Bazaar.

In Bazaar, copying "the whole repository" is easy, and costs about the
same as copying just one branch, but it doesn't mean anything special.
Whether or not you copy the entire repository, you will still have full
historical data for each branch you have locally, by default.  That's
the important thing, whereas copying "the repository" is mainly an
optimization, and does not have the same implications for local access
to historical data that it would in CVS.

Here's an example of creating an empty shared repository locally,
pulling one branch of upstream master Emacs into it, then cheaply
fetching another branch into the repository later:

  $ bzr init-repo emacs-shared-repository
  $ cd emacs-shared-repository
  $ bzr branch URL_TO_UPSTREAM_EMACS_TRUNK
  ### This will take a while, because it's the first fetch
  ### of a great many revisions.
  $ bzr branch URL_TO_UPSTREAM_EMACS_SOME_OTHER_BRANCH
  ### This won't take long at all, because most of the revisions are
  ### already present locally in the shared repository, thanks to the
  ### first branch -- bzr won't pull that data across the wire twice.

Of course, many people just save time by just copying the entire shared
repository at once; that takes about as long as the initial branching of
trunk would have in the example above.  This is what I did to fetch the
most recent test conversion of Emacs, for example:

  $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs emacs-bzr-repository

Now I have _all_ the branches locally, as if I had done 'bzr branch' to
get them.

In my earlier example, the "bzr init-repo ..." step above was optional.
The commands

  $ bzr branch URL_TO_UPSTREAM_EMACS_TRUNK

and

  $ bzr branch URL_TO_UPSTREAM_EMACS_SOME_OTHER_BRANCH

would still work even without a repository, it's just that a) the second
command would pull some data over the wire that the first command had
already pulled, and b) the two branches wouldn't share storage on local
disk, which could add up if you have keep lots of branches locally.

I hope this helps.

-Karl