<hr /><i>anonymous added on 2010-10-05 20:25:56:</i><br />
For fossil to be a practical alternative to cvs/svn/git/..., it has to perform well for at least two network related tasks:
(1) Initial clone
(2) Update of a recent enough clone.

The test case here is not effected by network bandwidth or latency. The test case is not bound by disk bandwidth either, since it is small enough to fit comfortably into memory. As such, it should be a lot faster. For example, I don't understand why it needs so many round trips. The initial clone is the easy problem, both side should know exactly what the other side has.

I wouldn't be surprised if this kind of problems don't happen with a less skewed distribution of the commits (1/3 of all commits to one file), but that doesn't mean it can't be done better. I'm going to try later with a repository that I can publish, so hopefully it can be sorted out.