[Monotone-devel] another db ? was: monotone evaluation in commercial project [long]

[rghetta]

I think this thread is derailing from my original intent.

I said that a corporate repository backed by an oracle/db2/whatever 
database would be more acceptable to management for a number of reason 
wich make sense from a manager perspective (if you prefer, think pointy 
haired boss).
These reasons doesn't necessarily have much technical sense when applied 
to monotone. It's more or less "marketing".
If I could say to my manager "monotone on server can use oracle for its 
backend", monotone would immediately gain some reputation.
The fact alone that monotone *can* use an "enterprise database" is 
enough, even if technically has little merit, and some real 
shortcomings, over the sqlite setup.
Thus, having another database as a backend for the central repository 
doesn't mean you need to allow concurrent access to it.
You can lock all the tables forever, if you like.
Usually you can't restrict read access (via sql, not another monotone 
process) and backup, but those do no impact monotone at all.
Speaking of backup, having to create a specific procedure to accomodate 
  monotone, even if is simple like making a shell script to sync a 
temporary repo, is something *against* monotone (again, from a manager 
POV, not mine).

To be clear, I personally think that SQLite is fine, especially on 
developer machines. A distributed scm using a centralized database is 
just downright silly.
Perhaps I should have asked about the feasibility of a compile-time 
option which uses, say, the odbc api instead of the sqlite one ...

Riccardo