regression? branching lp:branch into empty local shared repo is very slow

[Martin Pool]

2010/1/11 Andrew Bennetts <andrew.bennetts at canonical.com>:

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

It seems like in this case, you would want the server to send a packet
of revision ids, distributed through the history back to
null_revision.  Then the client can say if it has any of them.  This
ought to let you fairly quickly identify that it should send the whole
thing.

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

We've been a bit hit-and-miss with options like that in the past.
What is the context in which it would be turned on?

If somebody has already identified that the pull is too slow and
started looking into it, then the current logging seems almost enough.
 (Maybe you should log a traceback for places where this occurs?)

On the other hand if this was once working and was then accidentally
regressed, we need something stronger than an optional flag: either a
test, or if we're not confident a small test will catch all cases, a
warning that always occurs.

Perhaps we should look at a generic 'developer mode' debug flag,
meaning that the person is willing to get warnings about things that
have gone wrong but won't actually break immediate operation:
deprecated or slow apis, etc.  However, for this to work we would have
to keep it normally expected to be zero in trunk, otherwise it will
just be ignored.  (I believe there are some things caught be -Devil in
trunk that have been there fore a while, because they're apparently
not really evil enough to be urgent.)

-- 
Martin <http://launchpad.net/~mbp/>