regression? branching lp:branch into empty local shared repo is very slow
Andrew Bennetts
andrew.bennetts at canonical.com
Mon Jan 11 00:42:40 GMT 2010
John Arbash Meinel wrote:
[...]
> Looking at -Dhpss, I see a whole lot of:
> 187.259 hpss call w/body: 'Repository.get_parent_map',
> '~python-dev/python/2.5/', 'include-missing:',
> 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:47100'
> ('svn-v3-trunk1:6015fe'...)
> 187.259 97 bytes
> 187.560 result: ('ok',)
> 187.560 108 body bytes read
>
> Which looks like it is getting 1 revision and its parents at a time.
> Some of this is because the python branch is just very linear. However,
> I thought that 'Repository.get_parent_map' was supposed to expand the
> revisions requested. (Always return ~64kB of parent information per
> request.)
But if no results are found, it can't expand the results (if the heads()
were cheap to determine, I'd probably return those in this case, but
they aren't).
But what is supposed to happen is that _walk_to_common_revisions in
InterRepository should be requesting 50 revisions at a time, not just
one. If that's not occurring in this case, I think that is a regression
(and one we should add a ratchet test for to stop it regressing again).
Perhaps a new variation of -Dhpss is called for (just like -Dhpssvfs)
that shows a traceback whenever a get_parent_map request is sent with
just one key? Perhaps “-Dhpssevil”?
-Andrew.
More information about the bazaar
mailing list