Zack Weinberg wrote: > At this point I'm going to have to ask you to back up your claims with > actual design, if not actual code. Please look at the existing > database layer in Monotone (database.cc, schema.sql) and the higher > layers where most of the application-specific consistency constraints > are currently enforced (revision.cc, cset.cc, roster.cc, > roster_merge.cc). Please tell us in detail how you would take > advantage of SQL features that we are currently not using, to enable > additional concurrency. You can totally redesign the database tables > if you want. If at all possible, please distinguish between things > that could be done with SQLite and things that would require either > extending SQLite or switching to a new database implementation.
I'll have a look. While fetching the source I noticed that http://www.venge.net/mtn-wiki/SelfHostingInfo still mentions venge.net as the Monotone server, but that host is not listening on the netsync port. Changing it to monotone.ca works great. -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ One man's impedance mismatch is another man's layer of abstraction. (Lincoln Yeoh) _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel