[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers-public] Re: [Monotone-devel] Hosting multiple Monotone
[Savannah-hackers-public] Re: [Monotone-devel] Hosting multiple Monotone projects
Wed, 10 Aug 2005 03:14:05 -0700
On Wed, Aug 10, 2005 at 01:43:02AM +0200, Sylvain Beucler wrote:
> I recently studied Monotone, and I wonder if this is a VCS people
> would like to host at platforms such as GNU Savannah
> (http://savannah.gnu.org), and how.
> I would like to briefly discuss the how first: as far as I could see,
> the current server implementation is meant to serve one Monotone
> database/repository, with sequential access.
Concurrent access, actually, using one of them fancy no-threads
event-loop designs (though it probably needs some work to scale to
large repos + large numbers of concurrent connections, just because I
don't know of anyone who's really pushed it).
> In the case of Savannah, we would need to support potentialy 2000
> Monotone repositories, if possible with concurrent access (even if
> access is sequential per repository, maybe), and if possible without
> the need to run 2000 servers running on 2000 different ports :)
> Is there something I missed, or is the current Monotone server not
> meant for this kind of usage yet? Is it actually planned at all?
I'm very interested in this question, actually; I'd love for there to
be an easy way for people to get some low-key monotone hosting. As
you point out, it's currently not completely trivial, and some work
would be necessary to make it so; I'd definitely be behind any such
There are lots of different things that might make sense... the
simplest thing to do, maybe suitable to get off the ground if anyone
felt like starting such a hosting service right now, would just be to
give each project a port and run one process per port.
This is unaesthetic in its use of ports, and means you have a bunch of
processes cluttering your swap space, even when they're not in use.
Teaching a single monotone process to access multiple dbs would be
quite a pain, though, and not particularly helpful -- they don't share
much state, what state they _do_ maintain (caches and so on) would be
better kept separate -- and the OS can probably handle a
process-per-db model, OSes have all been optimized for apache's ol'
So my off-the-cuff suggestion for a more aesthetic setup would be to
put a proxy on your "monotone port", tweak the netsync protocol to
make sure that the first packet includes some sort of vhost parameter,
and then teach the proxy how to spawn monotone processes on demand and
forward traffic to them.
Or perhaps that's insane, I'm open to other suggestions :-)
> Now, maybe, as a distributed VCS, using Monotone at centralized sites
> like Savannah is of little interest. I find it difficult, though, to
> publish a repository, be it because of a corporate firewall or a
> hardly configurable xDSL router, so I think that's at least one
> possible interesting use.
No, you're quite right; while p2p systems give you fantastic
flexibility engineering-wise, you generally don't want to be using
that flexibility day-to-day, because it's a pain in the butt to always
be trying to figure out who's online and whether you can sync with
them. "Talking" is p2p too, but we still have bulletin boards and
pubs and all that... it's _far_ better to have a central location
that's always there, and where you know you can always get the latest
updates. Monotone's design make this much less of a _commitment_ than
conventional systems, one host is as good as another... but you do
> I should note that we don't plan to support Monotone right now (we're
> working on other issues at the moment), but I though it would worth
> asking in advance :)
"...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