Comment 14 for bug 672389

On Tue, 2010-11-09 at 12:33 +0000, Eric S. Raymond wrote:
> Jelmer Vernooij <email address hidden>:
> > All branches in bzr have an explicit path in the file system, the
> > repository is merely the place where the revisions happen to be stored,
> > unlike e.g. git where it also acts as more of a mechanism to group
> > related branches.
> OK, I went and read a bzr tutorial. If I believe the docs, bzr's model
> seems rather like CVS modules; in terms of J. Random Vanilla VCS, a
> bzr repo is like a collection of named repositories with nothing
> necessarily in common except the fact that they all happen to live in
> the same storage unit. (If I have this theory wrong, please correct me.)
That seems right, although s/repositories/branches/.

If you're used to git I think a better way of thinking about it is
probably as every repository only having a single branch.

> The trouble with this theoretical account is that it doesn't connect
> with what I see on my disk. When I create a bzr repo 'bzr-testrepo',
> add files there, and do checkins, I don't see any path structure that
> corresponds to "branches". Instead I see a single directory with a
> .bzr subdirectory in it. My commits have a "branch nick" property
> that shows up in the log, but it seems to be identical to the
> directory basename and thus doesn't convey any actual information.
How did you create such a directory ? "bzr init" ? That creates a
standalone bzr branch. The branch nick name isn't very useful until the
branch gets merged. It gets set to the basename of the directory by
default, but it can also be set explicitly.

> If I say "bzr-fast-export bzr-testrepo' I get what looks like an ordinary
> fast-import dump of the repo context. If I say "bzr-fast-export --no-plain
> bzr-testrepo' I get a fast-import dump with perfectly reasonable-looking
> property settings for branch-nick in it.
>
> So at what point does this mythical "branch" structure" assume any reality
> at all? So far, this looks like a git or hg repo in which the default
> branch happens to have the name of the directory basename. Is there
> any good reason the whole repo coudn't be exported as a collection
> of git branches, each corresponding to a bzr branch?
In theory, sure. In practice people don't necessarily use one repository
per project. Some people just have one repository in their home
directory, others have one repository per branch, etc.

There's some work happening to support "colocated branches", which work
similar to hg local branches or git branches (multiple branches for a
single file system directory).

> > > What's its syntax? Is it documented somewhere? I need to know enough to
> > > parse it.
> > I'm not sure if it's documented anywhere. I suspect it is, but that I
> > simply just don't know where.
> This, too, is a documentation bug.
I agree, although I'm not sure where. Is there some sort of fast
import/export spec?

> > As far as I can tell from the
> > python-fastimport sourcecode the format is something like this:
> >
> > "property" <space> NAME <space> VALUE-LENGTH <space> VALUE
> >
> > or, if the value is empty:
> >
> > "property" <space> NAME
> >
> > NAME and VALUE are utf8-encoded.
> >
> > The properties for each commit are sorted by the property name.
> Yup, I have to parse that. The property values could contain newlines.
>
> Is this feature scheduled for inclusion in core git?
Commit properties themselves are not scheduled for inclusion in core
git, I don't know whether there are any plans to add support for this
particular fastimport feature to "git fast-import". Even if they would I
wouldn't know what git fastimport would do with them - it could probably
only ignore them.

> Where can I find documentation on the bzr "fixes bug foo" extension
> mentioned on the web page? Is it just a property with the name
> "fixes-bug"?
There's a property named "bugs" that contains one line per bug. Each
line contains the URL of the bug followed by a space and a word
indicating what the commit does that particular bug (the only supported
value at the moment is "fixed").

Cheers,

Jelmer