bzr fast-import crashes on a dump produced by bzr fast-export

[Eric S. Raymond]

The attached dump was produced by bzr fast-export --plain. Feeeding it back to bzr-fast-import reliably crashes bzr,

$ bzr fast-import BAR
bzr: ERROR: exceptions.TypeError: 'list' object is not callable

Traceback (most recent call last):
  File "/home/andrew/code/bzr/bzrlib/commands.py", line 923, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/home/andrew/code/bzr/bzrlib/commands.py", line 1123, in run_bzr
    ret = run(*run_argv)
  File "/home/andrew/code/bzr/bzrlib/commands.py", line 691, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/andrew/code/bzr/bzrlib/commands.py", line 710, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/home/andrew/code/bzr/bzrlib/cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/home/andrew/code/bzr/bzrlib/cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/home/andrew/code/bzr-fastimport/trunk/__init__.py", line 377, in run
    info = self._generate_info(source)
  File "/home/andrew/code/bzr-fastimport/trunk/__init__.py", line 405, in _generate_info
    return_code = proc.process(p.iter_commands)
  File "/home/andrew/code/python-fastimport/trunk/fastimport/processor.py", line 65, in process
    self._process(command_iter)
  File "/home/andrew/code/python-fastimport/trunk/fastimport/processor.py", line 76, in _process
    handler(self, cmd)
  File "/home/andrew/code/python-fastimport/trunk/fastimport/processors/info_processor.py", line 195, in commit_handler
    for fc in cmd.file_iter():
TypeError: 'list' object is not callable

[Jelmer Vernooij (jelmer)]

  affects bzr-fastimport
  status invalid

  affects python-fastimport
  status fixcommitted

This should be fixed in python-fastimport trunk.

[Eric S. Raymond (esr-thyrsus)]

Jelmer Vernooij <email address hidden>:
> affects bzr-fastimport
> status invalid
>
> affects python-fastimport
> status fixcommitted
>
> This should be fixed in python-fastimport trunk.
>
>
> ** Changed in: bzr-fastimport
> Status: Confirmed => Invalid
>
> ** Also affects: python-fastimport
> Importance: Undecided
> Status: Fix Committed
>
> --
> bzr fast-import crashes on a dump produced by bzr fast-export
> https://bugs.launchpad.net/bugs/672389
> You received this bug notification because you are a direct subscriber
> of the bug.

Where can I pull a version with the fix committed?
--
  <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[Jelmer Vernooij (jelmer)]

On Mon, 2010-11-08 at 09:19 +0000, Eric S. Raymond wrote:
> Jelmer Vernooij <email address hidden>:
> > bzr fast-import crashes on a dump produced by bzr fast-export
> > https://bugs.launchpad.net/bugs/672389
> > You received this bug notification because you are a direct subscriber
> > of the bug.
>
> Where can I pull a version with the fix committed?
Of course, it helps when I actually remember to push the revision with
the fix... sorry about that.

The fix should be present in lp:python-fastimport now (revision 294),
which I've just pushed.

Cheers,

Jelmer

[Eric S. Raymond (esr-thyrsus)]

Jelmer Vernooij <email address hidden>:
> On Mon, 2010-11-08 at 09:19 +0000, Eric S. Raymond wrote:
> > Jelmer Vernooij <email address hidden>:
> > > bzr fast-import crashes on a dump produced by bzr fast-export
> > > https://bugs.launchpad.net/bugs/672389
> > > You received this bug notification because you are a direct subscriber
> > > of the bug.
> >
> > Where can I pull a version with the fix committed?
> Of course, it helps when I actually remember to push the revision with
> the fix... sorry about that.
>
> The fix should be present in lp:python-fastimport now (revision 294),
> which I've just pushed.

OK, I see that this is on a bzr branch. But I don't know how to install it.
Is there a ppa I can subscribe to? If not, can you set one up?

Explanation: I'm actually working on this:

http://freshmeat.net/projects/reposurgeon

I tripped over this bug while trying to extend reposurgeon support to
bzr. I'd like to (a) verify this fix, and (b) finish the bzr suppport.

If you're interested, I can also tell you how to make bzr-fast-export's
version of the export stream format more closely compatible with git's.
You don't have the whitespace in the format exactly right, but I can
tell you how to fix that. (The difference shows up in my regression tests.)
--
  <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[Jelmer Vernooij (jelmer)]

On Mon, 2010-11-08 at 10:57 +0000, Eric S. Raymond wrote:
> Jelmer Vernooij <email address hidden>:
> > On Mon, 2010-11-08 at 09:19 +0000, Eric S. Raymond wrote:
> > > Jelmer Vernooij <email address hidden>:
> > > > bzr fast-import crashes on a dump produced by bzr fast-export
> > > > https://bugs.launchpad.net/bugs/672389
> > > > You received this bug notification because you are a direct subscriber
> > > > of the bug.
> > >
> > > Where can I pull a version with the fix committed?
> > Of course, it helps when I actually remember to push the revision with
> > the fix... sorry about that.
> >
> > The fix should be present in lp:python-fastimport now (revision 294),
> > which I've just pushed.
>
> OK, I see that this is on a bzr branch. But I don't know how to install it.
> Is there a ppa I can subscribe to? If not, can you set one up?
I have a PPA with some bzr plugins packaged here:

https://code.launchpad.net/~jelmer/+archive/bzr-dailies

I've just requested new builds for python-fastimport and bzr-fastimport
that should hopefully kick off in the next hour. There are just packages
for Maverick at the moment, if you're running something else please let
me know and I'll add builds for that series as well.

> Explanation: I'm actually working on this:
>
> http://freshmeat.net/projects/reposurgeon
>
> I tripped over this bug while trying to extend reposurgeon support to
> bzr. I'd like to (a) verify this fix, and (b) finish the bzr suppport.
Ah, nice!

Since you're working on fastimport/fastexport streams you might also be
interested in the "VCS fast import/export developers" list at
https://launchpad.net/~vcs-fast-import-devs. The authors of the bzr, hg
and git fastexport/fastimport plugins hang out there. I wasn't aware of
reposurgeon and I'm not sure if the others are.

> If you're interested, I can also tell you how to make bzr-fast-export's
> version of the export stream format more closely compatible with git's.
> You don't have the whitespace in the format exactly right, but I can
> tell you how to fix that. (The difference shows up in my regression tests.)
As far as I know we're compliant with the spec, though I would be
interested to know in what way we're different from git's
fastexport/fastimport.

Cheers,

Jelmer

[Eric S. Raymond (esr-thyrsus)]

Jelmer Vernooij <email address hidden>:
> I have a PPA with some bzr plugins packaged here:
>
> https://code.launchpad.net/~jelmer/+archive/bzr-dailies
>
> I've just requested new builds for python-fastimport and bzr-fastimport
> that should hopefully kick off in the next hour. There are just packages
> for Maverick at the moment, if you're running something else please let
> me know and I'll add builds for that series as well.

I am running Maverick, and I see the updated package. Sadly, the popup
with installation instructions is broken; would you please fix that or
remind me of the magic incantation, please?

> > I tripped over this bug while trying to extend reposurgeon support to
> > bzr. I'd like to (a) verify this fix, and (b) finish the bzr suppport.
> Ah, nice!

It's fun project. I think it's the first *native* import-streams
application - that is, the first cross-VCS tool that relies
exclusively on the properties of the import format rather than knowing
details about many VCSes.

> Since you're working on fastimport/fastexport streams you might also be
> interested in the "VCS fast import/export developers" list at
> https://launchpad.net/~vcs-fast-import-devs. The authors of the bzr, hg
> and git fastexport/fastimport plugins hang out there.

I've joined and sent an intro posting on reposurgeon.

> I wasn't aware of
> reposurgeon and I'm not sure if the others are.

Unsurprising. The project is very new, at 0.4 and barely two weeks old.
I only announced it a week ago.

> As far as I know we're compliant with the spec, though I would be
> interested to know in what way we're different from git's
> fastexport/fastimport.

I believe you're compliant with the spec too. But your dump files don't
round-trip through my tool perfectly because of differences in optional
whitespace. I'll explain this in more detail on the list.
--
  <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[Jelmer Vernooij (jelmer)]

On Mon, 2010-11-08 at 14:36 +0000, Eric S. Raymond wrote:
> Jelmer Vernooij <email address hidden>:
> > I have a PPA with some bzr plugins packaged here:
> >
> > https://code.launchpad.net/~jelmer/+archive/bzr-dailies
> >
> > I've just requested new builds for python-fastimport and bzr-fastimport
> > that should hopefully kick off in the next hour. There are just packages
> > for Maverick at the moment, if you're running something else please let
> > me know and I'll add builds for that series as well.
>
> I am running Maverick, and I see the updated package. Sadly, the popup
> with installation instructions is broken; would you please fix that or
> remind me of the magic incantation, please?
Do you mean the "Technical details about this PPA" box? This seems to be
working for me at moment, what breaks for you?

The contents of the box are:

This PPA can be added to your system manually by copying the lines below
and adding them to your system's software sources.

deb http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
deb-src http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main

Signing key: 1024R/EB27448B
Fingerprint: CA7C60A52494B0FD5CD5292102949186EB27448B

> > > I tripped over this bug while trying to extend reposurgeon support to
> > > bzr. I'd like to (a) verify this fix, and (b) finish the bzr suppport.
> > Ah, nice!
> It's fun project. I think it's the first *native* import-streams
> application - that is, the first cross-VCS tool that relies
> exclusively on the properties of the import format rather than knowing
> details about many VCSes.
Yeah, I'm not aware of any similar tools at the moment. Unfortunately
the bzr and hg fastimport/fastexport streams are not yet lossless at the
moment, but things are slowly improving. The vcs-fastimport-devs list
was originally started to discuss extensions to the fastimport format,
and some have already made it in.

> > I wasn't aware of reposurgeon and I'm not sure if the others are.
> Unsurprising. The project is very new, at 0.4 and barely two weeks old.
> I only announced it a week ago.
Ah, cool. Thanks for sending the announcement, I'll give it a try next
time I need to do some repository surgery.

Cheers,

Jelmer

[Eric S. Raymond (esr-thyrsus)]

Jelmer Vernooij <email address hidden>:
> Do you mean the "Technical details about this PPA" box? This seems to be
> working for me at moment, what breaks for you?

Hm. I was getting an error message an hour ago, but now see instructions.
Must have been some transient database glitch.

> The contents of the box are:
>
> This PPA can be added to your system manually by copying the lines below
> and adding them to your system's software sources.
>
> deb http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
> deb-src http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
>
> Signing key: 1024R/EB27448B
> Fingerprint: CA7C60A52494B0FD5CD5292102949186EB27448B

I did this.

root@snark:/etc/apt/sources.list.d# cat jelmer-vernooij-bzr-fastimport.list
deb http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
root@snark:/etc/apt/sources.list.d#

I got an update of your dailies this way, though it complained of
being unable to authenticate. Then, because I like authentication, I
moved the manually-created repo entry to a .save and went
the add-apt-repository route.

root@snark:/etc/apt/sources.list.d# add-apt-repository ppa:rbelem/bzr-fastimport
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv 68D4D9D58AB348A98F3C5328BC67161E45243C2D
gpg: requesting key 45243C2D from hkp server keyserver.ubuntu.com
gpg: key 45243C2D: public key "Launchpad rbelem-main" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)

This appeared to succeed, but another attempt at upgrade just to check gave me
this:

Failed to fetch http://ppa.launchpad.net/rbelem/bzr-fastimport/ubuntu/dists/lucid/main/binary-amd64/Packages.gz 404 Not Found
Some index files failed to download, they have been ignored, or old ones used instead.

So I'm guessing there's a glitch in the PPA build chain somewhere. Shouldn't
these packages be arch-independent? Dropping back to your repo pointer from
rebelem's banishes that error but brings back the failure to authenticate.

> Yeah, I'm not aware of any similar tools at the moment. Unfortunately
> the bzr and hg fastimport/fastexport streams are not yet lossless at the
> moment, but things are slowly improving. The vcs-fastimport-devs list
> was originally started to discuss extensions to the fastimport format,
> and some have already made it in.

I'm going to propose two extensions based on my experience.

Now for the good news: with your update, I've done a successful bzr repo
build from a dumpfile. So that's one problem solved.

Now for more bad news.

esr@snark:~/software/bzr-testrepo$ bzr fast-export --plain
bzr: ERROR: command 'fast-export' requires argument SOURCE

What the hack is this "source" argument anyway? The on-line help fails to
explain it. I tried giving it an argument of "." but that crashed the
exporter. So did the dummy argument "FOO" that it was accepting before.

I note, in the on-line-help, this:

 * *commit-properties* - custom metadata per com...

[Jelmer Vernooij (jelmer)]

On Mon, 2010-11-08 at 16:35 +0000, Eric S. Raymond wrote:
> Jelmer Vernooij <email address hidden>:
> > The contents of the box are:
> >
> > This PPA can be added to your system manually by copying the lines below
> > and adding them to your system's software sources.
> >
> > deb http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
> > deb-src http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
> >
> > Signing key: 1024R/EB27448B
> > Fingerprint: CA7C60A52494B0FD5CD5292102949186EB27448B
>
> I did this.
>
> root@snark:/etc/apt/sources.list.d# cat jelmer-vernooij-bzr-fastimport.list
> deb http://ppa.launchpad.net/jelmer/bzr-dailies/ubuntu maverick main
> root@snark:/etc/apt/sources.list.d#
>
> I got an update of your dailies this way, though it complained of
> being unable to authenticate. Then, because I like authentication, I
> moved the manually-created repo entry to a .save and went
> the add-apt-repository route.
>
> root@snark:/etc/apt/sources.list.d# add-apt-repository ppa:rbelem/bzr-fastimport
> Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv 68D4D9D58AB348A98F3C5328BC67161E45243C2D
> gpg: requesting key 45243C2D from hkp server keyserver.ubuntu.com
> gpg: key 45243C2D: public key "Launchpad rbelem-main" imported
> gpg: Total number processed: 1
> gpg: imported: 1 (RSA: 1)
>
> This appeared to succeed, but another attempt at upgrade just to check gave me
> this:
>
> Failed to fetch http://ppa.launchpad.net/rbelem/bzr-fastimport/ubuntu/dists/lucid/main/binary-amd64/Packages.gz 404 Not Found
> Some index files failed to download, they have been ignored, or old ones used instead.
My PPA is ppa:jelmer/bzr-dailies, I'm not sure who rbelem is. :-)
 "apt-add-repository ppa:jelmer/bzr-dailies" should work and take care
 of importing the right GPG key.

It also looks like you're running on Lucid rather than maverick? Or
perhaps the error is referring to an old record?

> Now for more bad news.
>
> esr@snark:~/software/bzr-testrepo$ bzr fast-export --plain
> bzr: ERROR: command 'fast-export' requires argument SOURCE
>
> What the hack is this "source" argument anyway? The on-line help fails to
> explain it. I tried giving it an argument of "." but that crashed the
> exporter. So did the dummy argument "FOO" that it was accepting before.
I'm sorry, it looks like you picked the worst moment to try out
bzr-fastimport as I split python-fastimport out of bzr-fastimport (by
far the largest change in over a year) yesterday evening. This, like the
other issue you ran into, is unexpected fallout of that. I did some
fairly extensive testing of bzr fastimport before doing this split but I
still seem to've missed a few things and apparently uncovered some blind
spots in our testsuite.

The fast-export source argument is the source branch. The second
argument is an optional target file, which defaults to standard out. The
issue you're seeing is a bug, where the opening of stdout fails.
Expor...

[Eric S. Raymond (esr-thyrsus)]

Jelmer Vernooij <email address hidden>:
> It also looks like you're running on Lucid rather than maverick? Or
> perhaps the error is referring to an old record?

You know, I'm actually not sure how to tell. I upgrade rhe machine
incrementally; it's not giving me the notification that a system
upgrade is waiting, which caused me to believe I was up to Maverick
level. How would you check.

> I'm sorry, it looks like you picked the worst moment to try out
> bzr-fastimport as I split python-fastimport out of bzr-fastimport (by
> far the largest change in over a year) yesterday evening. This, like the
> other issue you ran into, is unexpected fallout of that. I did some
> fairly extensive testing of bzr fastimport before doing this split but I
> still seem to've missed a few things and apparently uncovered some blind
> spots in our testsuite.

Been there myself, and probably will be again; naive-user tests do have a way
of catching one with one's pants down. So I won't rant at you or anything. But
this leaves two issues:

1. The bzr help-import documentation neve anywhere I can see, explains
that the "source" argument is a branch name or what the namespaces and
semantics of branch names are. This is a documentation bug that needs
to be fixed.

2. What's a branch name? Why do I care? Does it select only part of the
repository? If so, why can't I leave it out and get all branches exported?
Is there some magic cookie I can put there that means "give me all branches"?

> > * *commit-properties* - custom metadata per commit that Bazaar stores
> > in revision properties (e.g. branch-nick and bugs fixed by this
> > change) will be included in the output.
> > If commit-properties are now officially part of the format, that's
> > one of my feature requests down - but I can't find any indication of
> > this in the git docs. What's the actual state of play?
> This is a bzr extension. I think bzr will emit it using the new
> "feature" extension that should be documented in the git docs. I'm not
> sure how official the commit-properties field is.

What's its syntax? Is it documented somewhere? I need to know enough to
parse it.
--
  <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[Jelmer Vernooij (jelmer)]

On Mon, 2010-11-08 at 20:39 +0000, Eric S. Raymond wrote:
> Jelmer Vernooij <email address hidden>:
> > It also looks like you're running on Lucid rather than maverick? Or
> > perhaps the error is referring to an old record?
> You know, I'm actually not sure how to tell. I upgrade rhe machine
> incrementally; it's not giving me the notification that a system
> upgrade is waiting, which caused me to believe I was up to Maverick
> level. How would you check.
It's usually easiest to look in /etc/apt/sources.list and see what the
latest distroseries is specified there (jaunty, karmic, lucid,
maverick).

> > I'm sorry, it looks like you picked the worst moment to try out
> > bzr-fastimport as I split python-fastimport out of bzr-fastimport (by
> > far the largest change in over a year) yesterday evening. This, like the
> > other issue you ran into, is unexpected fallout of that. I did some
> > fairly extensive testing of bzr fastimport before doing this split but I
> > still seem to've missed a few things and apparently uncovered some blind
> > spots in our testsuite.
> Been there myself, and probably will be again; naive-user tests do have a way
> of catching one with one's pants down. So I won't rant at you or anything. But
> this leaves two issues:
:-)

> 1. The bzr help-import documentation neve anywhere I can see, explains
> that the "source" argument is a branch name or what the namespaces and
> semantics of branch names are. This is a documentation bug that needs
> to be fixed.
Agreed; I've filed a bug report about this.

> 2. What's a branch name? Why do I care? Does it select only part of the
> repository? If so, why can't I leave it out and get all branches exported?
> Is there some magic cookie I can put there that means "give me all branches"?
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.

There is no way to export multiple branches at the moment.

> > > * *commit-properties* - custom metadata per commit that Bazaar stores
> > > in revision properties (e.g. branch-nick and bugs fixed by this
> > > change) will be included in the output.
> > > If commit-properties are now officially part of the format, that's
> > > one of my feature requests down - but I can't find any indication of
> > > this in the git docs. What's the actual state of play?
> > This is a bzr extension. I think bzr will emit it using the new
> > "feature" extension that should be documented in the git docs. I'm not
> > sure how official the commit-properties field is.
>
> 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. 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.

Cheers,

Jelme...

[Eric S. Raymond (esr-thyrsus)]

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

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.

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?

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

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

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"?
--
  <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[Jelmer Vernooij (jelmer)]

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

[Eric S. Raymond (esr-thyrsus)]

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