Comment 37 for bug 405251

> There should be no case that we take out a write lock on the source repository in order to read data.
I think you misunderstood; it is a push TO the target, and the target server has the lock. That is the server that the push data is being written to.

> 91% of the time is spent in "UNTIL_NO_EINTR" which is just waiting for data on a socket.
This is what I see: the client is deadlocked waiting for the server to sent data (it is in a recv).

> so that is 94s or 1m34s sending data.
That seems correct; it started to transmit 15MB of data to the server and then it blocked. Sending that data will take that time, the server is on a remote link. So the server was not packing at that time probably. (There is some huge problem here where bzr sends or receives way too much data for push/pull; the 200+ MB pull is not an exception but was seen a few times before. I get the impression that it reloads revisions it has already seen from the server time and time again.)

When the client (doing the push) was blocked (after the 2min) I checked the server and did the strace there; that server did not do anything at all. I tried again using bzr+ssh protocol which actually starts a bzr serve remote using an ssh pipe; that one hung at exactly the same time and doing an strace there revealed that it did completely nothing- it hung in a recv like the client (it did not poll or anything and did NO IO at all, the strace showed a single line for 10 minutes, then I cancelled). So this is 100% a protocol error somewhere - the server is *not* packing at all but blocking on recv.

Ok, back to the other stuff:
> You mentioned that this repository:
> 1) Used to have a lot more than ~10k files
No, when experimenting with bzr I found out that the #of files was a huge problem under Windows. So before I created this repository (from scratch, no import or whatever) I removed all files *before* creating the initial import. It has never seen the bigger number of files.

> 2) Had multiple independent ancestries pulled together.
It has been "merged with history" with a single other independent branch. That branch's bzr info (when in a standalone repo, zeroes removed) says:
In the working tree:
      1369 unchanged
       168 versioned subdirectories
Branch history:
       190 revisions
       127 days old
Repository:
       202 revisions

> 3) Has about 10-20k revisions.
I don't know if we are talking about the same thing, but bzr info -v for this repo tells me:
Branch history:
      1380 revisions
       426 days old
Repository:
      7265 revisions

> that means that you average almost 80 files changing for every commit
Well we do not work that hard at all 8-), actually your metrics sound very much like what we do (5..10 files average) - it is nowhere close to 80. There have been only a few (2 or so, but including merges) that changed 3143 files in one commit. But those were exceptional ones (CRLF fixes and source formatting fixes).

So all in all I do not understand the metrics we see here. Is there a way to associate those 100K text changes with their commits so that we can see if this is actually the case?