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

[rghetta]

On Sat, 2005-04-09 at 22:22 -0600, Derek Scherger wrote:
...
> 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.
Wonderful.  Next week I will try to build from dev.

> 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.
Gee. Monotone is advancing much faster than I used to see. Perhaps the
ml is now a bit behind events. Time to hang out on IRC ... 

> >  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.
Oops. I assumed you were able to access certs and manifests directly
with sql. This is worse than I expected.
Currently our reports are somewhat limited because VSS is accessible
only through its automation interface, and this makes everything much
more painful.  
To have a searchable database we must more or less read the VSS tree and
dump the relevant informations in a custom database, then run the
queries from here.
Monotone situation seems somewhat comparable, because even a simple
"what errors were corrected this week" requires the same process,
despite having a SQL engine underneath.
Don't get me wrong: monotone is much much better because has changesets,
but the base process seems the same.
Perhaps is naive from me expecting monotone database be exploitable by a
reporting tool or having the ability to export in a format suitable.

> > 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.
Sorry, I tried to shorten my post, but just made it confusing.
I was talking about the central "official" repository (remember, I
consider monotone in a corporate environment), not the local developer
copies.
Currently monotone can't access its database concurrently. This isn't a
big problem from a distributed POW, since you communicate with netsync.
Unfortunately this also means that the corporate repository could be
backed up safely only while offline, and this is simply unacceptable.
Besides, even small corporations usually have already some centralized
database, with established procedures for backup/restore, disaster
recovery, security and so on.
A solution able to fit into this existing infrastructure is viewed as
"more advanced" even if a bit slower.
I mentioned Oracle and DB2, but obviously you can apply everything at
your preferred SQL database (MySQL, postgres, firebird, etc).
The real questions thus are: 
how portable is monotone in this respect ? 
SQLite has its peculiar type system and abilities.  Monotone depends on
these ?
What performance hit do you expect using another database ? 
>From a quick look at the sources everything seems pretty standard SQL,
but obviously performance is another thing.

                Thank you very much,
                                Riccardo