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

[Kevin Greiner]

Personally, I think the whole "monotone should use
[oracle|postgresql|mysql|odbc]" discussion is a big distraction.
Monotone just happens to use an internal storage mechanism that just
happens to have a SQL "api". From a manager's perspective, monotone's
storage is a binary black box. It certainly doesn't fit the typical
"application using sql database" and therefore needs a custom data
backup procedure. That's common enough. 

If, for instance, monotone had decided to use a file-system oriented
approach, we wouldn't even be having this discussion. Unless people
tried to share their filesystem "db" using NFS. Ugh.

On 4/15/05, rghetta <address@hidden> wrote:

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

_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel