|
From: | Timothy Brownawell |
Subject: | Re: [Monotone-devel] automate serve? |
Date: | Sun, 26 Sep 2010 15:45:13 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100821 Iceowl/1.0b2 Icedove/3.1.2 |
On 09/26/2010 09:36 AM, Stephen Leake wrote:
In implementing the DVC front-end for automate sync, I've run into a problem. If I use ssh: or file: netsync schemes, the mtn process that is started outputs startup error messages that are not properly packetized for automate stdio. For example, if the path to the database is wrong, I get something like; 0:p:114:connecting to file:///Projects/monotone/monotone.netsync.automate-build_cygwin/tester_dir/tests/working/test2.db?*mtn: misuse: database /Projects/monotone/monotone.netsync.automate-build_cygwin/tester_dir/tests/working/test2.db does not exist Here the string up to the first "test2.db?*" is properly packetized, but the next part is plain text; the error message. If the serve connection is started without errors, it performs and terminates cleanly. The mtn process is running 'mtn serve ...'. I think the correct solution to this is to implement 'automate serve', so that the error messages are properly packetized. That should be easy; CMD_NO_WORKSPACE(serve ...) in cmd_netsync.cc is short, and should not need any modification; I can just copy it into a CMD_AUTOMATE(serve ...). Any thoughts?
The client should replace the server's stderr with a pipe that it adds to the select loop and feeds to its own packetized error stream.
But our PipeCompatibleProbe is written to only handle *either* multiple (network) connections *or* a single pair of pipes (one in, one out); I think due to Windows treating these fairly differently. I'm not sure how involved reworking this would be.
An alternative would be that if the server is started with --stdio, it should suppress warnings and dump errors to stdout as a error_cmd. This would be fine for errors encountered before starting the actual netsync connection, but if sent later it would have to go through the session's buffering. We already have code to catch errors hit during netsync and send them as error_cmd's, so this might not even be too hard.
Either way is probably involved enough that we wouldn't want to try to stuff it into 1.0, particularly since it sounds like you've got a decent workaround.
-- Timothy Free public monotone hosting: http://mtn-host.prjek.net
[Prev in Thread] | Current Thread | [Next in Thread] |