On Tue, Feb 20, 2007 at 02:46:41PM +0000, Joel Crisp wrote:
> /unlurks ;-)
Cool, welcome back! :)
> I'm toying with the idea of building a small experimental app on top
> of monotone. The app has the following characteristics:
>
> There are three integration points I could conceivably use:
>
> 1) automation [monotone automate]
Definately the most supportable/stable integration interface. With
stdio, you get to keep the db open and use mtn's caches as well,
though there could be some locking issues if you also try to open via
a separate mtn for writes.
If the interface is inadequate for your needs, we want to know why and
to fix the interface.
Note that not all automate commands are necessarily read-only; in
particular there are some read-write ones coming as part of the
cvs_sync rework. So again, improving the automate interface to include
what your app needs is the preferable way to go.
> 2) importing the monotone headerfiles and some cpp code and building a
> new C++ app which uses the underlying monotone C++ types
> 3) hit the DB directly
also possible, at the risk of much less interface stability. schema
changes are relatively common, for example. might be ok for
prototyping an experimental app, but best avoided if possible.
There's also potentially:
4) make it part of monotone proper
which may or may not suit your idea.
> I think from my previous understanding that (1) is the preferred
> option, but I am worried about performance, particularly on very large
> databases (just one of our apps is 77,000+ files with over 50
> developers). Also, (2) gives me lua essentially for free.
>
> Thoughts?
>
> (You may also get monotree updated too as part of this.)
Cool. It also needs to use automate, rather than trying to parse log
output.. :) There's been work recently on an eclipse plugin which has
some other components for interfacing with automate from java.
> On a side topic, not being able to sync with the monotone master
> repository from behind our corporate firewall/proxy is a bit of a
> pain. Does anyone have a way to access the venge.net repository over
> HTTP tunneling? That and FTP is all our firewall will let through, and
> there is no way I will ever be able to change that.
This is a frequent request. I hope to soon be able to host a nvm.dumb
replica that you can at least pull from over http.
--
Dan.