Re: svn commit: r20033 - in branches/merge-tracking/subversion: include libsvn_repos svnserve

[Greg Hudson <gh...@MIT.EDU>]

On Mon, 2006-06-12 at 12:13 -0700, Daniel Rall wrote:
> The first nested tuple should be a list.  I think I need to add an
> ellipses to indicate that.
> 
> Also, "rev" should be an optional parameter (the server defaults to
> "youngest" -- the protocol doc might want to indicate that, too).
> Does "rev" need to be placed in a tuple, or can it simply be preceded
> by a question mark?

With all due respect, there's nothing unique about this request; you can
just look at how other commands handle similar constructs.

You're correct on the first point.  On the second point, use the same
optional-tuple syntax used by every other command, which puts the
argument inside a tuple.  That way the command can be extended to
include more optional arguments.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r20033 - in branches/merge-tracking/subversion: include libsvn_repos svnserve

[Greg Hudson <gh...@MIT.EDU>]

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

Re: svn commit: r20033 - in branches/merge-tracking/subversion: include libsvn_repos svnserve

[Daniel Rall <dl...@collab.net>]

On Mon, 12 Jun 2006, Greg Hudson wrote:

> On Mon, 2006-06-12 at 12:13 -0700, Daniel Rall wrote:
...
> > Also, "rev" should be an optional parameter (the server defaults to
> > "youngest" -- the protocol doc might want to indicate that, too).
> > Does "rev" need to be placed in a tuple, or can it simply be preceded
> > by a question mark?
> 
> With all due respect, there's nothing unique about this request; you
> can just look at how other commands handle similar constructs.

I did, but as this is my first foray into any serious svnserve/ra_svn
modifications, I appreciate the confirmation.

> ... On the second point, use the same optional-tuple syntax used by
> every other command, which puts the argument inside a tuple.  That
> way the command can be extended to include more optional arguments.

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?

The 'get-dir' command has a trailing optional "list" type elment which
is not enclosed in a tuple.  Is the tuple implicit for the "list" type
case?

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

Daniel Rall