Re: [Monotone-devel] is monotone for me?

[Stephen Leake]

Gour <address@hidden> writes:

> So, we spent some time reading the (very nice) docs (what are you
> using for documenting?). 

The manual is written in texinfo.

> I read Concepts & Tutorial fully and skimmed more quickly through the
> rest. Now we have some questions in order to discern whether monotone
> is the right tool for our needs.
>
> We want robust system which can serve us for many years,
> multi-platform support (that's why we abandoned gtk2hs & wxhaskell and
> decided to use Qt toolkit.) with possibly some GUI tool for Mac/Win
> users/devs not too familiar with cli. 

mtn works on Linux, Mac, and Win32 (native and Cygwin). Some features
are not supported on Win32 native, but all work on Win32 Cygwin.

There is an Emacs front-end called DVC. I consider that a GUI, but some
people don't. I maintain it, and it almost eliminates the need for mtn
command line.

> a) what do you find as the reason for not wider acceptance of
> monotone? (I know darcs is not too popular as well, but, at least, it
> is used widely within Haskell community.) Is there something which is,
> according to the public criticism lacking in monotone or it is simply
> a fact that "it's too different and not named Xit"?

One issue is the version number; 0.48 sounds "experimental". There will
be a 1.0 soon.

> b) there are some possibilities for hosting darcs repos, but,
> according to the wiki, there is only one site offering public hosting
> for monotone. Do I miss some?

If you use ssh access, there is very little admin burden for a mtn
server; just creating user accounts.

The mtn version on the server does not have to be up to date; the
netsync protocol changes very slowly.

> c) considering b) it seems practical to think about using one's own
> hosting for the project, I'm curious about memory requirements on the
> server (for medium-sized project)?

Obviously, it needs a medium-sized memory :). mtn uses sqlite for the
backend database; that reads the entire database into memory.

With ssh access, only one user can access the db at a time; that reduces
the memory requirements over running multi-user access. That doesn't
work well if you have _lots_ of users (since the probability of
collisions goes up). But the time each user locks the database is pretty
short, so it really is _lots_ of users. Sorry, no numbers; it also
depends on the work flow; how often each user syncs.

> d) similar to Fossil, monotone is a bit isolated in its own universe
> due to the lack of interoperability tools.

Can you be more specific? Which tools in particular are not there?

-- 
-- Stephe