Comment 15 for bug 672389

Jelmer Vernooij <email address hidden>:
> 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.

I'm used to git and hg, which on this issue are nigh-indistinguishable.

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

bzr init is what I used, yes.

Ah, I see. So the branch nick only becomes significant when you push the
branch to a repo that is *not* a standalone branch?

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

I had to stare at these paragraphs a while before I understood them.
Now that I think I do, I regret to report that don't think I like bzr
much. The model of branching you're describing manages to be
overcomplicated and weirdly restrictive at the same time. The hg/git
model is far simpler to understand.

Sigh. I'll still support bzr in reposurgeon as well as it lets me. As
I noted in email to your Samba address, I'm now round-tripping --no-plain
dumps perfectly, and import is working, but export is crashing in its
cleanup function.

I still think the branch argument to export should be optional and it should
export all branches when none is specified.

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

Only the git one, that I know of. I think I'd start by adding a section
to the bzr-fast-import page that includes the syntax descriptions you've
given me for the commit-properties and bugs features.

> > Yup, I have to parse that. The property values could contain newlines.

And I have done so; reposurgeon now fully supports commit-properties.

> Commit properties themselves are not scheduled for inclusion in core git,

I think I need top prod the git crew about this.

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

This should go on the bzr-fast-import page.
--
  <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>