[Monotone-devel] Re: New project: libmtn

[Bruce Stephens]

Arseny Nasokin <address@hidden> writes:

> On Thu, Jun 29, 2006 at 11:01:33PM +0100, Bruce Stephens wrote:

[...]

>> It is??
>> 
>> Seems unusually low in bugs to me.
>> 
>
> yes, on small projects. But does you try commit into it FreeBSD CVS
> mirror?! (there about 3GB of CVS, without mails, gnats and www)

Well, importing CVS is tough for most systems (it's easier with
subversion).  I think that's a difficulty that's intrinsic to the
problem, isn't it?  Are you sure the difficulty with FreeBSD's CVS
aren't just inevitable?

[...]

>> What benefit would have that?  (This has been discussed before---some
>> time ago, but I doubt things have changed that much.  Come to think of
>> it, one thing that *has* changed a bit is the realisation that hg is
>> so much faster (at least at some things)---using a network database
>> seems unlikely to help.)
>> 
>> 
> monotone very dislike lock-wating.
>
> Example:
>  you open net service.
>  you checkout from same file on same machine.
>  you try _sync_ with _network_ service, which uses _same_ file.

In English there's a joke "Doctor, it hurts when I do this.  Well,
don't do that, then."

> as result you get crearly closed network service(mtn pidfile
> removed) and no syncing.
>
>
> AFAIK, SqlLite3 is good for small projects only :(

There are probably limits to the scaling, yes.  I'm not convinced
using a beefier (network) database will help that much, though.

I guess it might permit a tradeoff of poorer performance which scales
better.

That seems like a limited niche, though.  For example, as far as I
understand it BitKeeper worked so fast for the linux people because
the whole repository fit in memory.  So I suspect there's many more
projects that have repositories that are <500M (using most systems)
than significantly bigger than that.

If you have a 3G repository, probably not every developer will want
their own copy, so I guess you're more looking for a centralised
system.

Or one which doesn't have monotone's current restriction that every
repository needs to have all the ancestors of every revision that it
contains.  That seems a much more useful direction to look in than
using a different database, IMHO.