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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 10.09.10 16:08, schrieb Stephen Leake:
>> 
>> 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. 

Done.

>> 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.

Agreed.

> 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.

Good point.

>> 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.

Right; my current application can just filter the output.

> 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. 

That makes sense. The non-automate version could still have zero output.

> (Hey, remember that we already raised the major automate version
> because of au genkey -> au generate_key?)

I'll persue the hook option a little farther (see other email). I don't
think this should hold up 0.99.

> 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.

Does this really need to be in the ticker? Can't automate sync output
data incrementally in the main stream?

-- 
-- Stephe