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

[Justin Patrin]

On 6/29/06, Arseny Nasokin <address@hidden> wrote:
> 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

Well, since you seem stuck on this rewriting, I really suggest you do
it in concert with the monotone developers, asking for help and doing
it so that it can be merged back into monotone. If you just do it on
your own you could quite likely end up with code that "works", but
won't be accepted back into monotone due to any number of things.

Then again, I'm not a monotone developer and I don't make any of these
decisions. I'm just giving advise as an Open Source developer.

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

Bugs such as? Again, very few bugs have been found with the current
code. There are some decent sized projects using monotone and monotons
has gotten far less buggy in a very short time. If you are seeing
bugs, report them...

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

These are design issues, not bugs.

--
Justin Patrin