Re: [Monotone-devel] automate serve?

[Timothy Brownawell]

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