Re: [Monotone-devel] New project: libmtn

[Arseny Nasokin]

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