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