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

[Nathaniel Smith]

On Sun, Apr 10, 2005 at 10:54:16PM +0200, rghetta wrote:
> 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.

It is quite simple to back up a monotone database while it is online;
your developers do it all the time :-).  "netsync"'s basic operation
is exactly to copy everything in one database into another and
vice-versa.  Ergo, all of your developers's local copies are themselves
backups, as is the special database that you set up specifically as a
backup server, with the cron job that just calls "monotone pull"
periodically.  Monotone really does try to make it quite hard to lose
data...

In fact, every one of those databases is a _hot_ backup; if something
goes wrong with the central db, you can just run "monotone serve" on
another machine and go on using that one until the main server is
repaired.  This actually happened to monotone some months ago, when
graydon upgraded the venge.net server and then left to a conference
before we realized that the new version had serious netsync bugs.  We
fixed the bugs and kept going while he was gone by just getting some
people with reasonable connections to run their own local servers;
development didn't even slow down.

If you don't fully trust this, of course, you can also just take the
server down for a few minutes once a week, run 'db dump', and back up
the resulting text file, with minimal disruption to work.  (People can
even commit etc. while the server is down :-).)

> 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 ? 

no idea.

> SQLite has its peculiar type system and abilities.  Monotone depends on
> these ?

probably not much; we don't store anything besides strings anyway.

> What performance hit do you expect using another database ? 

no idea.

> >From a quick look at the sources everything seems pretty standard SQL,
> but obviously performance is another thing.

Porting monotone to use a different database is certainly possible,
but probably a bad idea.  It's not safe to have multiple monotone
processes running against the same database, not because sqlite isn't
up to this, but simply because we haven't done the careful auditing of
the monotone source that would be required to make this safe... so
doing this wouldn't give the benefits that people usually hope it
would, like letting developers point their monotone's directly at the
server machine.  If _all_ you want is a "more accepted" database
backend, it makes a little bit of sense, but gives you absolutely no
technical advantages, and gives you a number of technical
disadvantages.

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff