[18:20] bzr shell was too fiddly last time I tried to use it. Mercurial actually has fully functional background program for this. [18:21] Or rather, bzr shell really really isn't designed for non-interactive/scripting use. [18:27] https://www.mercurial-scm.org/wiki/CommandServer [18:32] FWIW on POSIX platforms you can just send CWD and stdio file descriptors over unix socket, so it can work pretty seamlessly. I wish there was a generic Python module for that, as the start up time for a lot of software is really bad. [18:34] Yah; it's a common thought. It's basically just "do FastCGI" [18:34] The "Fast" part of FastCGI is really just a UNIX process server system, it has verylittle to do with CGI or webserving or anything else [18:35] Connect to a socket, send initial environment, stream stdin in, stream stdout / stderr back out, accept exit code at the end [18:37] It's a hack ultimately. Workaround for slow startup time. But there is only so much you can do with Python to speed it up. [18:47] It's a nice idea regardless of the language though. It means programs can open database connections, precache things,.. whatever they need.. [19:08] Idea is nice, how many edge cases you will run into depends on how you use it. But with shoveling all of env/cwd/stdio into it the rest is pretty much inherent issues of preloading libraries. [19:20] And signals, which also need special handling. Oh well, operating systems are messy. :-] [19:41] CcxWck: are you sure you're talking about 'bzr shell' and not 'bzr service'? [19:41] The latter is a background service [19:42] The former is just a way of not paying for cache load/import time repeatedly