bzr version-info very slow

Bug #882541 reported by Gerard
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
Lawrence Mitchell

Bug Description

I'm using bzr version-info --custom --template="{branch_nick}.{revno} to construct a version number within the code as per recommended usage in bzr help version-info. However, it's very slow - typically 4-6 seconds!

strace seems to indicate that it's stalling communicating with launchpad:
write(3, "0.665 ssh implementation is Ope"..., 37) = 37
socketpair(PF_FILE, SOCK_STREAM, 0, [4, 5]) = 0
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
pipe([6, 7]) = 0
fcntl(7, F_GETFD) = 0
fcntl(7, F_SETFD, FD_CLOEXEC) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5929da79f0) = 20349
close(7) = 0
mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5924b07000
read(6, "", 1048576) = 0
mremap(0x7f5924b07000, 1052672, 4096, MREMAP_MAYMOVE) = 0x7f5924b07000
close(6) = 0
munmap(0x7f5924b07000, 4096) = 0
close(5) = 0
sendto(4, "bzr message 3 (bzr 1.6)\n\0\0\0\34d16:"..., 108, 0, NULL, 0) = 108
brk(0x2266000) = 0x2266000
recvfrom(4, "bzr message 3 (bzr 1.6)\n\0\0\0'd16:"..., 65536, 0, NULL, NULL) = 86
...delay here

However, it would seem that all the information required is local. For example:
grep "^\(bound\|parent\)_location" .bzr/branch/branch.conf | sed 's/.*${PACKAGE_NAME}\///' | sed 's/\/$//'
from the source directory will give nick while bzr revno --tree gives the revno.

I'm using:
Bazaar 2.4.1-1ubuntu1
Ubuntu 11.10

Related branches

Revision history for this message
Martin Packman (gz) wrote :

Lawrence, your branch fixing this looks reasonable, do you want to propose it for merging into Bazaar so we can work out how to write a test to verify it resolves the issue?

Revision history for this message
Lawrence Mitchell (wence) wrote :

Done

Martin Packman (gz)
Changed in bzr:
assignee: nobody → Lawrence Mitchell (wence)
importance: Undecided → Medium
status: New → Confirmed
Martin Packman (gz)
Changed in bzr:
milestone: none → 2.5b3
status: Confirmed → Fix Released
Revision history for this message
Lawrence Mitchell (wence) wrote :

I'm not sure that the patch that's landed actually fixes the original report's problem.

There seem to be two issues:

1) stat()ing files on slow filesystems should be avoided if possible (the merged branch does this)

2) getting the branch nickname requires contacting the upstream server in the case of bound branches when no local nick is set.

For custom templates we can get around this problem with the following patch:

=== modified file 'bzrlib/version_info_formats/format_custom.py'
--- bzrlib/version_info_formats/format_custom.py 2011-06-12 20:09:55 +0000
+++ bzrlib/version_info_formats/format_custom.py 2011-11-09 12:38:14 +0000
@@ -87,7 +87,8 @@

         info = Template()
         info.add('build_date', create_date_str())
- info.add('branch_nick', self._branch.nick)
+ if '{branch_nick}' in self._template:
+ info.add('branch_nick', self._branch.nick)

         revision_id = self._get_revision_id()
         if revision_id == NULL_REVISION:

In general I don't see an easy way to avoid this network traffic without changing the information stored locally for bound branches.

One possible option would be to add a field to branch.conf: upstream-nickname = ...

This could be updated on clone, plus any subsequent fetches, to act as a cache for the upstream nick.

Lawrence

Revision history for this message
Martin Packman (gz) wrote :

Hm yes, had overlooked the original report, using bound branches does also cause network access - unless the branch nick is set locally. So, the command given in the bug report will still be slow for emacs until the local copy has `bzr nick emacs-bound` or similar run. Does this need adding to the emacs getting started documentation?

Revision history for this message
Lawrence Mitchell (wence) wrote :

I'm not sure what emacs has to do with the original bug report, but in any case, I'd argue that the round-trip requirement for bound branches to get the nick is a poor choice. At some point in the past, this must have not been the case (see lp:148030). But I note it's also reported as an issue in lp:629150.

As I mentioned previously, I think branch.conf should store this one (extra) piece of information for bound branches to avoid round-tripping when looking for something as simple as the branch nickname. Whether this should just be done by overloading the nickname field, or by adding an additional field, I don't know.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

We discussed this a bit during our standup today. Martin suggested having "bzr checkout" set the local branch nick by default, which is a very simple fix to make it hard to get into this situation.

There are more things we can do, but this this should fix the issue for most people and is a fairly simple change.

Revision history for this message
Martin Packman (gz) wrote :

Okay, let's carry on in bug 629150 rather than confusing things further here (sorry Gerard!)

Revision history for this message
Glenn Morris (rgm+lp) wrote :

I understand from bug 629150 that how to handle nicks is still under discussion.
In the meantime, please could the trivial fix from comment #3, point 2), on this bug be applied?
Then people using custom templates not including the nick won't need to wait.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.