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

[Thomas Keller]

Am 06.10.10 14:56, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
>> Am 02.10.2010 11:30, schrieb Stephen Leake:
>>> [...] So this is an Emacs DVC problem, not a mtn problem.
>>>
>>> Which means that the nvm.netsync.automate branch is ready, except the
>>> --dryrun stuff is not tested or documented; I'll work on that.
>>
>> Coolness, drop me a note when you finished it and I'll review it. This
>> branch will then contain all the previous work from Tim, right?
> 
> This is now complete, and all tests pass on Mingw and Debian (Cygwin
> tests running, very slowly with some failures).
> 
> This includes Tim's work on 'sync --dry-run', and my work on basic_io
> output from 'automate sync'.

My observations so far:

1) Even though --dryrun is given, mtn gives a lot of unneeded chatter,
especially the following:

mtn: bytes in | bytes out | revs in | revs out
mtn:   10.1 k |    13.4 k |       0 |        0
mtn: successful exchange with <server>
mtn: note: your workspace has not been updated

Could we prevent the initialization of the transfer tickers and hide the
"note: your workspace has not been updated" message by disabling the
optional workspace updater?

2) If a sync would not push anything, the output is:

   mtn: would send 0 revisions:

It would be better if the colon is removed, so it looks less like "hey,
something is missing here". Yes, that means one additional string to
translate, but thats not a big problem.

3) If multiple branch certs are attached to a single revision, this
revision of course pops up (and is counted) multiple times in the final
result. Would it make a lot of work to group these a little smarter,
i.e. not counting revisions by any single, but multiple branch?
Something which would lead to an output like

mtn: would send 5 revisions:
mtn:         2 in branches first.branch,
mtn:                       second branch
mtn:         3 in branch first branch

?

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/)

We could make it ourselves easy now and just change the documentation
accordingly, but are value-less, symbol-only lines really something we
want to have / introduce?

5) Likewise the non-dry-run format "symbol symbol" which is used like
"receive revision" or "send key" is not defined either. While the set of
possible values is predefined here, it might be better to just put them
in double quotes.

6) Under what circumstances are received certs listed under "received
cert" and at what time under "received revision"? If only a certificate
is transferred, but not the revision of this certificate? Do we really
need a cert-grouping-by-revision in first instance or wouldn't it be
enough to have one format where each cert stanza always gets an identifying

        revision [123abc]

at the end? Maybe it would also be a good idea to make the format a bit
more flat, i.e.

send_revision [123abc...]

send_cert "branch"
    value "net.venge.monotone"
      key [123abc...]
 revision [123abc...]

receive_revision [123abc...]

receive_cert "author"
....

so we and the implementor has to rely less on the particular placement
of the information. Remember that data hierarchies and dependencies are
still quite hard to model with such a simple format.

7) Right now there is a line-break between the send and the receive
stanza implemented, but in monotone.texi this is missing:

+The following is example dry-run main channel data:
address@hidden
+  dryrun
+ receive
+revision "0"
+    cert "1"
+     key "1"
+    send
+revision "1"
+    cert "6"
+     key "1"
+  branch "foo2" "1"
address@hidden verbatim

8) Please read again over the "Output format" section in monotone.texi -
some sentences sound incomplete to me, but then I'm not a native speaker
either, so don't hit me if everything is correct :)

9) For the sake of consistency - would it make sense / is it possible to
unify the basic_io output for the dry-run and non-dry-run version when
we know what we want to push somewhere? I understand that we have no
information of incoming items we just haven't received yet, but we
should surely have the information for the outgoing items, right?


The code and tests look otherwise very clean and consistent - if the UI
/ documentation / functionality issues are worked out, I'd probably take
another look at it.

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