Re: [Monotone-devel] New project: libmtn

[Nathaniel Smith]

On Fri, Jun 30, 2006 at 05:44:25PM +0400, Arseny Nasokin wrote:
> > 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)

Ah, thanks, the bug tracker search interface was defeating me.  So I
guess a list of your bugs is here:
https://savannah.nongnu.org/bugs/index.php?group=monotone&set=custom&report_id=101&submitted_by=50329

AFAICT, #16867 and #16884 are fixed in 0.27, #16883 is a simple known
bug that we need to get around to fixing, but the operation that
triggers it (deleting absolutely everything in your workspace) is not
very common so the priority isn't very high, and #16911 is something
that we've been working towards with the attr stuff, but no-one has
expressed interest in pushing that forward into a working
implementation (but perhaps this is changing, see recent mailing list
thread).

> some others:
> 
> - TODO: drop is not recursive (macro command problem)

Yes it is:
  $ mtn drop --help
  [...]
  Options specific to 'mtn drop':
    [...]
    -R, --recursive       also operate on the contents of any listed
                          directories
    [...]


> - TODO: I cannot disapprove merging

Correct.  This is because no-one knows how to make such a thing that
works.  (The analogy would be, complaining about a math library
because it does not have a constant-time factoring algorithm.
Certainly the designers would love to add such a thing, but...)

We could make disapprove of merge work just like disapprove of
non-merge, of course, but it turns out that this is very much the
wrong thing to do, and has very surprising behavior.  If you have:
   a
  / \
 b   c
  \ /
   d
  / \
 b   c

as the result of disapproving a merge, and you re-do the merge now,
the result is not "d", but "a" (!).

> - revisions can be complex (why it? why not per-action?), _so_ can't be 
> disapproved. split revisions?

You still have not said what you mean by "complex", so I can't
really comment on this.

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

The info pages are intended to be exhaustive, and mostly succeed.  If
you have found lacks in them, then those are bugs, and we would like
to be informed of them.

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

Elsewhere you say that it will be kept private for many months.  Which
is it?

> resources? what do you mean? time? people? computers?

Yes :-).

> > > - one library - many frontends:
> 
> calling executable is very expensive operation from any lang, except shell 
> where it's normal.

Not true -- see "mtn automate stdio", which amortizes the cost.

> > 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?!

Because no-one has written them.

You haven't answered the question about speeding up development?


Well, I continue to suspect that you could reach your goals faster by
working with the existing solutions the community has hashed out,
rather than going off and trying to do your own thing.  But obviously
that's your option, either way; we'll continue to be happy to take any
improvements back, and please do continue to report bugs you encounter
and problems you have.

-- Nathaniel

-- 
.i dei jitfa fanmo xatra