Re: [Monotone-devel] Re: New project: libmtn

[Arseny Nasokin]

On Thu, Jun 29, 2006 at 11:49:47PM +0100, Bruce Stephens wrote:
> 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?
> 


Yes, about after 300 branches commited in (about 500'000 revisions). The 
message from ZSH: killed

> [...]
> 
> >> 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.
> 

Git is only for one developer :(
I shoul buy BitKeeper. I don't want do it, becaouse it isn't very good for me.
SVN, CVS are very bad (code, administration,etc)

-----------------

I want update my OS from monotone (not CVSUp)

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

I remember for you:
        database -  library   - <user-usable service>
        model    - controller - view

        extreme programming

I plan to build two big monotone cluster service for my work and public.
Now I plan open public monotone after libraried version

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

No, for small projects SqlLite3 is better.

Nowadays monotone has many bugs, because there are no clarity with poining it.

for example: 

design lacks: I can't disapprove revision for _one_ file from it. or it is 
possible create revisions, which are complex, not simple.
backend migrating: It's too hard write simple frontend for migrating from {CVS, 
SVN,...} to monotone and back.
designing:  Monotone have _inside_ basic command set, user have only complex: 
it's too hard write new command, which bases on basic command set.

-- 
   Best regards,
        Arseny Nasokin