on the fly conversion seems to cause issues for some repositories
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
New
|
Undecided
|
Unassigned |
Bug Description
I'm not really sure what's going on here but I do have a reproducer so I'm going to file and see if anyone has any ideas:
On my server, I have a shared repo with an older format:
bzr://bzr.
$ bzr info
Shared repository (format: pack-0.92)
Location:
shared repository:
On my client, I have bzr-.2.1.1:
$ bzr --version
Bazaar (bzr) 2.1.1
Python interpreter: /usr/bin/python 2.4.3
Python standard library: /usr/lib/python2.4
Platform: Linux-2.
bzrlib: /usr/lib/
Bazaar configuration: /home/fedora/
Bazaar log file: /home/fedora/
If I do a branch to a regular directory, things work fine:
$ bzr branch bzr://bzr.
Branched 571 revision(s).
If I first create a shared repository and branch into there, the process gets stuck at some point:
$ bzr init-repo .
Shared repository with trees (format: 2a)
Location:
shared repository: .
$ bzr branch bzr://bzr.
Doing on-the-fly conversion from RemoteRepositor
This may take some time. Upgrade the repositories to the same format for better performance.
/ 16803KB 290KB/s | Fetching revisions:Inserting stream
At this point, CPU usage by the bzr smart server on the server jumps up. Meanwhile, according to strace the client is just waiting for more data to be sent.
Something about shared repositories appear to be causing the issue. Any clue?
If the process hangs for (say) an hour, and server isn't in deep swap
and thrashing, then we should get a backtrace in python of the server
thread and see where it is at.
However, if the process does resume, then its explanable: the server
is doing an on the fly conversion to 2a, and the first bit converted
is the inventory, which is also the crucially bad-big-O component of
the pack-92 series of formats.
-Rob