On Mon, 2006-06-12 at 15:11 -0700, Daniel Rall wrote:
> That makes sense. The 'change-rev-prop' and 'log' commands don't
> conform to this pattern, as their trailing optional elements aren't
> enclosed in a tuple. Do they predate this pattern?
Ah, sorry, I see where the confusion comes from. Both of those commands
use a different pattern as the result of protocol changes. The
change-rev-prop value argument was at one time mandatory, while the log
limit argument is only "optional" in the sense that pre-1.3 clients
don't know to send it, not that we would ever choose not to send it.
get-dir's last argument is similar, as is diff's last argument.
> Lastly, some optional elements are enclosed in optional tuples (that
> is, their enclosing tuple can end before the optional nested tuple
> ever begins). Is this a pattern we want to continue?
Basically, in the protocol document, "? field" means "new field", while
"[ field ]" means "optional field". In the case of status, there was a
new optional field: not only would an old client not send the field at
all, but a new client might choose not to send it because there isn't
always a revision to specify.
>From the server's perspective, "the client was too old to send it" isn't
usually different from "the client chose not to specify it". But
extending status with "?(?r)" means that another new field might be
added in the future, making the end of the format specifier look like
"?(?r)?b" or something.
For a new command, the protocol document should use only brackets, not
question marks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 13 01:14:26 2006