| monotone implementation notes␊ |
| -----------------------------␊ |
| ␊ |
| 1. general␊ |
| ␊ |
| This branch contains an implementation of the monotone automation interface.␊ |
| It needs at least monotone version 0.47 (interface version 12.0) or␊ |
| newer. To set up a new project with monotone, all you need to do is␊ |
| to create a new monotone database with␊ |
| ␊ |
| $ mtn db init -d project.mtn␊ |
| ␊ |
| in the configured repository path ('mtn_repositories'). To have a really␊ |
| workable setup, this database needs an initial commit on the configured␊ |
| master branch of the project. This can be done easily with␊ |
| ␊ |
| $ mkdir tmp && touch tmp/remove_me␊ |
| $ mtn import -d project.mtn -b master.branch.name \␊ |
| -m "initial commit" tmp␊ |
| $ rm -rf tmp␊ |
| ␊ |
| ␊ |
| 2. current state / internals␊ |
| ␊ |
| The implementation should be fairly stable and fast, though some␊ |
| information, such as individual file sizes or last change information,␊ |
| won't scale well with the tree size. Its expected that the mtn␊ |
| automation interface improves in this area in the future and that␊ |
| these parts can then be rewritten with speed in mind.␊ |
| ␊ |
| Another area of improvement is the access pattern to the monotone␊ |
| database. While only one process is started per request, the time␊ |
| (and server resource) penalty for this could still be dramatic once␊ |
| many clients try to access the service. Luckily, monotone has an␊ |
| easy way to deliver its stdio protocol for automation usage over the␊ |
| network (mtn au remote_stdio), so the following scenarios are possible:␊ |
| ␊ |
| a) setup a single mtn server serving one database on a different␊ |
| (faster) server and let the stdio client connect to that␊ |
| ␊ |
| b) setup usher (available from branch net.venge.monotone.contrib.usher␊ |
| from the official mtn repository on monotone.ca) as proxy in␊ |
| front of several local monotone databases mirroring themselves␊ |
| ␊ |
| c) like b), but use usher as proxy in front of several other remote␊ |
| monotone databases (forwarding)␊ |
| ␊ |
| The scenario in a) might be needed anyways for a shared hosting␊ |
| environment, because a database which gets served via netsync cannot␊ |
| be accessed by another local process at the same time (its locked then),␊ |
| so ideally both, the network functionality as well as the indefero␊ |
| browsing functionality should be delivered from one single database␊ |
| per project via netsync.␊ |
| ␊ |
| The only alternative for this setup is a two-database approach, where one␊ |
| database acts as network node and the other as backend for indefero.␊ |
| The synchronization between these two would then have to happen via␊ |
| standard tools (cron...) or a sync request from one database to the other.␊ |
| ␊ |
| While the current implementation is ready for the two database approach,␊ |
| some code parts and configuration changes have to happen for the remote␊ |
| stdio usage. Bascially this is replacing the initial call to␊ |
| ␊ |
| mtn -d project.mtn au stdio (Monotone.php, around line 74)␊ |
| ␊ |
| with␊ |
| ␊ |
| mtn au remote_stdio HOSTNAME␊ |
| ␊ |
| which could be made configurable in conf/idf.php. But again, this heavily␊ |
| depends on the exact anticipated server setup.␊ |
| ␊ |
| To scale things up a bit, multiple projects should of course use␊ |
| separated databases. The main reason for that is that while read access␊ |
| can be granted on a branch level, write access gives total write␊ |
| possibilities on the whole database. One approach would be to start␊ |
| one serve process for each database, but the obvious downside here is␊ |
| that each of those processes would need to get bound to another␊ |
| (non-standard) port making it hard for users to "just clone" the␊ |
| project sources without knowing the exact port.␊ |
| ␊ |
| Usher comes to the rescue here as well. It has three ways␊ |
| to recognize the request for a particular database:␊ |
| ␊ |
| a) by looking at the requested host name (similar to SNI for Apache)␊ |
| ␊ |
| b) by evaluating the requested branch pattern␊ |
| ␊ |
| c) by evaluating the path part from an mtn:// uri (new in mtn 0.48)␊ |
| ␊ |
| The best way is probably to configure it with c) - instead of pulling␊ |
| a project like this␊ |
| ␊ |
| $ mtn pull hostname branchname␊ |
| ␊ |
| a user uses the URI syntax (which will, btw. be the default from␊ |
| mtn 0.99 onwards):␊ |
| ␊ |
| $ mtn pull mtn://hostname/database?branchname␊ |
| ␊ |
| Here, the "/database" part is used by usher to determine which backend␊ |
| database should be used for the network action. The "clone" command␊ |
| will also support this mtn:// uri syntax, but this didn't made it into␊ |
| 0.48, but will be available from 0.99 and later.␊ |
| ␊ |
| ␊ |
| 3. indefero critique:␊ |
| ␊ |
| It was not always 100% clear what some of the abstract SCM API method␊ |
| wanted in return. While it helped a lot to have prior art in form of the␊ |
| SVN and git implementation, the documentation of the abstract IDF_Scm␊ |
| should probably still be improved.␊ |
| ␊ |
| Since branch and tag names can be of arbitrary size, it was not possible␊ |
| to display them completely in the default layout. This might be a problem␊ |
| in other SCMs as well, in particular for the monotone implementation I␊ |
| introduced a special filter, called "IDF_Views_Source_ShortenString".␊ |
| ␊ |
| The API methods getPathInfo() and getTree() return similar VCS "objects"␊ |
| which unfortunately do not have a well-defined structure - this should␊ |
| probably addressed in future indefero releases.␊ |
| ␊ |
| While the returned objects from getTree() contain all the needed␊ |
| information, indefero doesn't seem to use them to sort the output␊ |
| f.e. alphabetically or in such a way that directories are outputted␊ |
| before files. It was unclear if the SCM implementor should do this␊ |
| task or not and what the admired default sorting should be.␊ |
| ␊ |
accountmanagementengine