[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] New project: libmtn
From: |
Arseny Nasokin |
Subject: |
Re: [Monotone-devel] New project: libmtn |
Date: |
Fri, 30 Jun 2006 17:44:25 +0400 |
User-agent: |
mutt-ng/devel-r581 (FreeBSD) |
On Fri, Jun 30, 2006 at 01:38:29AM -0700, Nathaniel Smith wrote:
> Pulling pieces from several of your emails together to respond...
>
> On Fri, Jun 30, 2006 at 01:51:27AM +0400, Arseny Nasokin wrote:
> > Monotone is good, but buggy :(
>
> Have you told us about any of these bugs? I can't find any reports
> from you in the tracker or on the mailing list.
>
I'm user `tarc' in bug-tracking system (email hided)
some others:
- TODO: drop is not recursive (macro command problem)
- TODO: I cannot disapprove merging
- revisions can be complex (why it? why not per-action?), _so_ can't be
disapproved. split revisions?
- TODO: documentation:
many commands, listed in man and info pages are not really exists (but
useful!)
`help' command is very short. man page is small. info pages are not
informative
you can see difference with gcc info and man pages, or svn `help'
command
documentation has good tutorial, but no full information about options, for
every command.
> > I have started project of recomposition monotone from one big
> > monotone commandline-oriented executable into monotone library (it
> > can be static), commandline utility, and possibly network service.
> > And work plan for me and my programmers group had created also.
> > First versions I plan deploy at my site next month.
>
> This is a bit unclear... are you planning to start from the existing
> code base and refactor it, or rewrite things from scratch? What kind
> of resources are you planning to put into this?
>
libmtn project realisation:
- refactor exiting, but be always be up-to-date and 100% compatiable
(one-per-hour from your db syncing is good, or it should be frequently?)
- code will be produced ASAP.
- all steps will be open to anyone
- be modulus.
resources? what do you mean? time? people? computers?
> > - one library - many frontends:
calling executable is very expensive operation from any lang, except shell
where it's normal.
> > - one library - many backends:
> > what about PostgreSQL or Oracle, not only SqlLite 3 as now?
>
> This could simply be added to the existing code base. I'm not
> convinced it's a good idea -- concurrency is very hard. it's not
> just SQLite that doesn't support it; we've been reluctant to guarantee
> that our code is safe in the presence of concurrent writes. In
> practice, it's almost impossible for people to accomplish this sort of
> thing without sacrificing robustness (and definitely sacrificing
> development speed). Also, the only case I know of where concurrency
> is really useful is for things like ViewMTN, that currently have no
> clean way to pull new changes.
>
backend is module.
frontend - also.
library translates requests from frontend and send them to backend.
> >From what testing we've done, SQLite seems to scale just as well as
> "more serious" databases when it comes to the size of the data stored;
> it was performant on our old 3-gig GCC repository tests. It's just
> concurrency where it is limited. (Present monotone may not scale that
> far, of course, just because it hasn't been tested and optimized
> there.)
>
SQLLite doesn't support clustering and networking
> Nonetheless, even if (in the worst case) you ended up not being able
> to convince us that this was useful for mainline, you're always
> welcome to maintain an enhanced fork of monotone in a
> net.venge.monotone branch. Nothing changes minds like experience and
> working code, and this would certainly be easier than redoing
> everything.
>
I know it, my work will be public, so you can give me a point, where _your_
tests are fail.
> > - new development will be faster.
>
> Can you elaborate? Library-ifying, by itself, can only slow
> development, because when you expose an intermediate API, that's
> something that's expensive to change. In a monolithic codebase, you
> can rearrange anything at any time, as improvements are discovered.
> (This requires a good test suite, of course, but we have one.)
>
Git, for example, provide small microcommands, which can be safely used in
scripts, which provide complex commands
why not them here?!
> > design lacks: I can't disapprove revision for _one_ file from it.
>
> This is simply a missing feature, not a design problem. Supporting
> 'revert -r' has been on the TODO list for a while, and should be
> reasonably straightforward to implement (not entirely trivial because
> there are some workspace handling refactors that probably need to be
> done first, but completely trivial to anyone who can redo the
> codebase, so.) This has simply been waiting on someone to get around
> to it; if you have resources to devote, we would love to accept
> patches for this.
>
> > 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 seem to simply be complaints about how rich the programmatic
> interface we expose is? By far the most expedient way to improve
> these would be to extend the 'automate' interface as needed. As
> mentioned above, the bottleneck for 'automate' is simply finding
> people who want to work on it, and have the use cases that you need to
> design a proper API. If you wanted to put effort into this, again, a
> lot of people would be happy.
>
No, for example I have software, which can produce only diffs for something
text. I want save it into _one_ place. This is simple nonstandart frontend
example.(debug commands?!!!)
> > Monotone is critical service for my buissines
>
> Well, we're flattered! You are, obvious, free to do what you like
> with the code and design. I suspect, though, that you'll find that
> making dramatic improvements turns out to be more difficult than your
> description makes it out to be -- this is just based on experience
> working on these issues, and the way that some of your goals seem to
> conflict (e.g., increasing robustness while adding features that are
> harder to make robust). I'd urge you to carefully consider all the
> ways you could work with the existing efforts in our community to
> accomplish the kinds of improvements you want. These changes can be
> implemented immediately, and immediately benefit everybody, while
> eventually working towards the kind of system that you want.
>
--
Best regards,
Arseny Nasokin
Re: [Monotone-devel] New project: libmtn, Justin Patrin, 2006/06/29
Re: [Monotone-devel] New project: libmtn, Nathaniel Smith, 2006/06/30
Re: [Monotone-devel] New project: libmtn, hendrik, 2006/06/30
Re: [Monotone-devel] New project: libmtn, Thomas Moschny, 2006/06/30
Re: [Monotone-devel] New project: libmtn, Nathaniel Smith, 2006/06/30