[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: New project: libmtn
From: |
Arseny Nasokin |
Subject: |
Re: [Monotone-devel] Re: New project: libmtn |
Date: |
Fri, 30 Jun 2006 03:22:55 +0400 |
User-agent: |
mutt-ng/devel-r581 (FreeBSD) |
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