Re: [Monotone-devel] automate sync display branches?

[Thomas Keller]

Am 10.09.10 16:08, schrieb Stephen Leake:
> I'm currently using a variation of examples/display_branches.lua to show
> what branches are transfered during a sync.
> 
> This works nicely when sync is run from a shell command line, but it's
> not so nice when run from automate stdio. I'm trying to enhance Emacs
> DVC to support a nice sync interface; it will display which workspaces
> need updating after a sync.
> 
> First, the messages are written directly to stderr, which screws up the
> stdio packetizing. 
> 
> After fixing that, the messages are in the progress stream, where they
> are not easy to parse.
> 
> I'd like them to be on stdout, in basic_io format.
> 
> So I wrote another variant of display_branches.lua that does that. But I
> only want that version when running a sync command in a stdio session. I
> tried specifying an 'rcfile' option for the sync command; it was
> accepted but silently ignored. rcfiles are only processed in
> monotone.cc:cpp_main, when the 'automate stdio' command is run.

While I wouldn't go down that route for your specific problem, please
still note it in the tracker so we do not forget it. I'd agree with both
solutions, either warn / disable on --rcfile usage in stdio or simply
allow it and document that we don't care if the user screws around with
the lua function stack.

> It would be nice if we got an error for an rcfile option on a stdio
> command; not clear how to accomplish that.
> We could try processing rcfiles for each stdio command, but I suspect
> that would not be good. For example, unless we can 'undo' each rcfile
> after each command, the effects would be cumulative, and thus impossible
> to trust. Unless we rerun _all_ rcfiles for each command; that would be
> consistent with running from a shell command line. Still messy to
> maintain separate lists of "original" and "new" rcfiles, so we know
> which ones to run.

Way too complex. A quick google search pointed me at
http://www.keplerproject.org/venv/ which would enable different
sandboxed "environments" where functions are executed independently from
each other, but I highly doubt that the amount of work to implement that
would pay off well here.
Other than that I think its also hardly possible to "recreate" a proper
lua state by executing different rc files in order - older files could
rely on functionality which has been changed by newer files previously
executed and therefor refuse to work, for example.

> Better would be to not use rcfiles for this purpose, which means adding
> C++ code to 'automate sync' to output the branch names, enabled by an
> option --output-branch-names.

I agree that some native functionality should be preferred here - and I
think we have multiple options.
At first I wouldn't restrict the output simply to branch names, but list
pushed / pulled certs, keys and revisions.
Then I'd make this the regular output of automate push / pull / sync,
simply because these commands do not have a payload beside tickers and
progress messages yet, so the switch you were talking about would most
likely only make sense if we absolutely want to preserve support for the
"old", zero-size output. (Hey, remember that we already raised the major
automate version because of au genkey -> au generate_key?)

Also note the current ticker implementation. We could - in theory -
change that implementation in a way that we not only notify the user
that "something has arrived" or "was sent", but output _what_ has
actually arrived or was sent. This would of course make sense for
long-spinning sync actions where you don't want to let the user wait for
the action to complete to already see intermediate contents.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature