Re: [Monotone-devel] Re: results of mercurial user survey

[Justin Patrin]

On 4/27/06, Nathaniel Smith <address@hidden> wrote:
> On Thu, Apr 27, 2006 at 11:28:27AM +0200, Koen Kooi wrote:
> > Pulling the monotone repo could have been nearly twice as fast, since
> > almost half of the revisions are merges. 'commit before update' is
> > great, but PR wise you are shooting yourselves in the foot IMO.
>
> Well, maybe.  We _should_ be fast enough that it doesn't matter,
> though :-).  (We also could make the initial pull go at line speed
> trivially, if we wanted; just feed the raw data straight out of the db
> and straight into the other side's db.  It's just that we're still
> trying to see how far we can get with "safe" before we give it up.)
>
> Also, data point: in the monotone repo, only ~1/5 of the revisions are
> merges.  (Presumably this varies with a group's habits.)  Getting rid
> of 1/5 of the revisions probably would make things somewhat faster,
> it's true... in monotone's case, it was only a few months ago that we
> _had_ 4/5 as many revisions as we do now.
>
> Using a pull of net.venge.monotone is slightly problematic as a
> benchmark, because the benchmark data set has been growing larger
> almost as fast as we've been optimizing :-).
>

For those of you who don't know we've "solved" this problem for
OpenEmbedded by having a "snapshot" database for download on a system
which is updated every night. This was when people are just starting
they can grab the snapshot and pull only a few revisions. Having
someone pull the entire OpenEmbedded database over netsync is really
problematic as it takes hours and hours to finish and most people want
it *now*.

To be fair, 0.26 does look to be faster, but an initial pull is still
going to take far too long on a decent sized database. IMHO an initial
pull into an empty DB could be changed to not verify revisions (as
this is the extremely long and complex part), although if there is a
possibility for corruption in netsync this could be a problem
(although I don't see how there could be, assuming it's over TCP).

Then again, maybe the best solution *is* the snapshot idea which we're
already using.

--
Justin Patrin