On 14/10/16 11:59, A. Soroka wrote:
...

6/ Packets of change.

To have 4 (label a patch with reversible) and 5 (the version details), there 
needs to be somewhere to put the information. Having it in the patch itself 
means that the whole unit can be stored in a file.  If it is in the protocol, 
like HTTP for E-tags then the information becomes separated.  That is not to 
say that it can't also be in the protocol but it needs support in the data 
format.

As long as the sort of information about which we are thinking makes sense on a 
per-transaction basis, that could be as I suggest above, as "metadata" on BEGIN.

So a patch packet for a single transaction:

PARENT <UUID>
VERSION <UUID>
REVERSIBLE           optional
TB
QA ...
QD ...
PA ...
PD ...
TC
H <sha1sum>

where QA and QD are "quad add" "quad delete", and "PA" "PD" are "add prefix" and 
"delete prefix"

I'm suggesting something more like:

TB PARENT <UUID> VERSION <UUID> REVERSIBLE
QA ...
QD ...
PA ...
PD ...
TC H <sha1sum>

Or even just positionally

TB <UUID> <UUID> REVERSIBLE
QA ...
QD ...
PA ...
PD ...
TC <sha1sum>

An "HTTP header"-like form (key-value lines) would be better because it is an open design where new header fields can be put in as needed. (e.g. "Author", "Date", "Signed-off-by").

It could be done as a different style, maybe identical to HTTP, so the patch specific parsing begins at the first TB, or include a blank line or marker like "----". Or the header could reuse the same parsing tokens, though values may end up in strings for grouping more often.

        Andy



Reply via email to