Greetings all,
I was using monotone for a bit last year, and liked it, but I switched
to darcs because there were two things I couldn't stand about monotone:
1. The fragile state-based depot system
2. Couldn't publish a repo on a dumb server
Recently, I have become a bit disenchanted with a darcs, so today I was
researching the state of the art among distributed RCS's. Imagine my
surprise when I saw that monotone has fixed problem #1 above! Woo-hoo!
Problem #2 is still a concern for me, however. I want people to be able
to publish repos on cheap web host servers (like $3/mo), where you
certainly can't run a cgi program, and probably don't even have SSH
access. Some variation of this seems to be a common desire among
prospective monotone users.
It seems to me that implementing this capability on top of monotone
might not be that hard. I haven't seen any concrete proposals like this
in the list archives. I'll lay out my thinking here, and if it seems
feasible, I'll probably code it up in a few weeks (unless someone else
does it first).
Fundamentally, I want to export the database to plain files, and then be
able to import those files to a different database. Once we have that,
the files themselves can be rsync'd or ftp'd or WebDAV'd to a web
server, and can easily be read from there.
First off, a question/assumption: Is it true that, aside from the merkle
table and the deprecated depot tables, records in the database are only
inserted or deleted, and never updated?
Ok. Implementation: I picture an exporter that updates a directory tree
based on the current contents of a database, and an importer that
updates a database based on a directory tree.
I think this can all be done outside of monotone itself, at least as a
prototype. Each of these can be written in a scripting language (I would
use Ruby), invoking monotone to perform the actual database access. It
would probably use the packet I/O calls, combined with a bit of raw
debug SQL as needed.
My interest is primarily in small projects, so I just want to get
something working quickly. Scalability can come later. Taking a modest
example, the current monotone database has fewer than 1500 rows in each
table. Thus, for now at least, the exporter could create one
subdirectory for each table, and simply export each row into its own
file. Later, it could be more sophisticated to better handle
multi-thousand row tables.
That's it. What am I missing or forgetting? What parts are likely to be
more difficult than I have made them sound? Does someone else want to
attempt this before I will have a chance to?
Thanks,
Kevin
P.S. I'm not subscribed to the list at the moment, so please CC me on
replies.
_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel