Re: [Monotone-devel] monotone evaluation in commercial project [long]

[Derek Scherger]

rghetta wrote:
> Somewhat surprisingly, monotone performance is survivable for add/commit
> (nine minutes is not fast, but you don't add 7000 files every day) but
> horrible for status/update.

some good progress has been made on this in the current development 
version. status on a tree of ~26000 files used to take 6m29s and now 
completes in 26s for me using the current head for example.

> Commit granularity:  the restrictions support is a giant leap forward,
> but, if I am right, you can restrict only a single filespec, not a list
> of specs (or a file containing the specs).

you can list as many files as you like to be included, assuming you 
don't run into command line length restrictions. the current development 
also includes a --xargs/-@ option that should allow for a file (or files 
if the option is repeated) including all the paths you want to include.

>  From a project manager point of view, the reporting ability of monotone
> is currently limited, unless you go directly at the SQL level.

are there any particular reports that you would find useful? going at 
the raw database wouldn't be very helpful as everything is base63, 
gzipped blobs that might only be xdelta diffs.

> Speaking of SQL, how dependent is monotone on SQLite ?
> Silly as it seems, *optionally* running a repo with Oracle or DB2 as
> backend would boost monotone acceptancy to management.

possible, but the performance might also be bad. monotone is quite 
chatty in terms of database traffic and sqlite happens to handle this 
really well, compared to out of process, talking over a socket, databases.

HTH

Cheers,
Derek