Re: [Monotone-devel] automate sync remote process startup

[Stephen Leake]

Stephen Leake <address@hidden> writes:

>>>> 4) For nvm.basic_io-doc Tim wrote in monotone.texi:
>>>>
>>>>   Each "symbol" is followed by one or more 'string's and/or 'hex'es.
>>>>
>>>> The basic_io format for sync / push output is not correct by this
>>>> definition, as the "send" and "receive" symbols are not followed by one
>>>> string / hash. (see also
>>>> http://code.monotone.ca/p/monotone/issues/85/)
>>> 
>>> Good point. 
>>> 
>>> This format is supported directly by the basic_io stanza class; it has
>>> push_symbol.
>>> 
>>> It is used in conflict resolutions, for 'resolved_internal'.
>>
>> Oh well, we should really have defined the format earlier... I didn't
>> stumble upon this in the conflicts code because I haven't implemented
>> that yet in guitone. Given that this is public already in other
>> commands, we should probably adapt the description in Tim's branch.
>
> Ok, I'll do that.

This is now done.

>> Don't take my wrong sorting in the above use case for granted, we could
>> still print out the certs sorted, even grouped. My point was more to
>> strip down the complexity of the format a little.
>
> Good point; the sort order does not have to be implied by the format,
> and the format does not have to take advantage of the sort order.
>
> I would not mind a flatter format that maintained the sorting, if it
> really does make Guitone easier. Then your parser can assume no context,
> but my parser can still rely on the context defined by the sorting :).
> that's not a big change in my parser; just redefining some strings, and
> ignoring revs in some certs.
>
> That would also make it easier to add other sort orders (selected by
> options), for other use cases, which would be good.
>
> So I'll give that a try.

This is now done.

> And I'll add some of this to nvm.basic_io-doc

I modified it to allow single symbols not followed by any data.

I started to add some discussion about "stanzas are context-free", but
that actually contradicts what's already there; "lines and stanzas are
required to be in a particular order ... the logical structure is nested
more deeply than the basic_io format can represent".

So we have conflicting desires for the higher-level restrictions on
basic_io format. Which is probably why this didn't get documented before
:).

I changed it to say "some commands have required order, others are less
restrictive".

>> So what I was heading for here was a unification of push / pull / sync
>> in no-dry-run and push / sync in dry-run mode, because in the latter
>> use case we should have all the local data available. For push / sync
>> in dry-run mode all we can probably really print are the raw numbers.
>> To make the format less distinct it _might_ be a good idea to print
>> these data also for the non-dry-run mode, so implementors don't have
>> to count the received cert stanzas if they're just after the raw
>> numbers and they could also have a check whether they processed
>> everything.
>>
>> My main point is to make the output format of push/pull/sync as
>> consistent as possible for both, the dry-run and the non-dry-run use
>> case.
>
> Right, I'll give that a try.

I looked into this. It's not worth it; the cert info is not stored, so
there's nothing worth outputting beyond the counts.

So nvm.netsync.automate and nvm.basic_io-doc are ready for review.

-- 
-- Stephe