On 08/17/2012 02:07 PM, Branko Čibej wrote: > On 17.08.2012 20:01, C. Michael Pilato wrote: >> On 08/17/2012 12:43 PM, Daniel Shahaf wrote: >>> Stefan Sperling wrote on Fri, Aug 17, 2012 at 18:24:03 +0200: >>>> On Fri, Aug 17, 2012 at 12:14:31PM -0400, C. Michael Pilato wrote: >>>>> 4. something else? >>>> 4. Marshall the version string before sending it across svn://, >>>> escaping unsupported characters somehow in a reversible way, >>>> and unescape them before passing them to hooks? >>>> I.e. use something like strnvis() but adapted to the >>>> restrictions of the svn:// protocol. >> Yeah, I forgot to add that I was thinking about this approach, too. I'm not >> familiar with strnvis(), but I assume it's similar to what we do with our >> checksum API _readable() variants (where 'A' is 0x41 and represented as as >> "41")? >> >>> 5. Require the version string and client name to match >>> /^[A-Za-z0-9-]+$/, and embed them directly as part of a capability >>> name (so: capabilities might be named client-version-tsvn-1dot7dot0) >> I'll give the honor of treating this suggestion as a serious one. And then >> the dishonor of a hearty -1. :-) > > Why? It's essentially the same as 4., just with a different and > higher-level marshalling.
Because it is higher-level marshaling. The ideal scenario keeps our restrictions and conversion costs as close to the layers that actually require them as possible. 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. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
