On 08/17/2012 03:11 PM, Greg Hudson wrote:
> On 08/17/2012 02:35 PM, C. Michael Pilato wrote:
>> I'm sitting at this spot right now: Unless we want hooks parsing literal
>> capability strings such as "client-version-tsvn-1dot7dot0", we have to
>> change the server. And if we have to change the server *at all* to make
>> this all work, then we should simultaneously change the protocol so as not
>> to require some still-obscure marshaling mechanism.
>
> I would expect a client version to be communicated over libsvn_ra_svn in
> a string, not a word. The original design intent was that words are
> only for enumerated protocol values understood by the ra_svn code itself.
>
> It seems like we departed from this design with #2991 when we made a set
> of ra_svn words visible to hook scripts. That seems like a mistake,
> just as it would be a mistake to put C identifiers into the UI.
>
> Anyway, for the case at hand, I think the client version needs to be
> marshalled as a string, not a word, and therefore not as a capability.
So, we marshal client-version/client-name/client-compat-version as strings
(as we do ""ra-client" and "client" now). Extant servers ignore them. New
servers are format those things in the way we've indicated elsethread
(ensuring that they match the specific regexp, slapping the likes of
"client-version=" on the head of them, etc.), merge them with the
capabilities array, and hand them to the start-commit hook.
Is that what you're proposing?
Or should we give these things unique placeholders in the start-commit
argument list rather than allowing them to masquerade as capabilities?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-08-17 21:25:53 CEST