Branko Čibej wrote on Fri, Aug 17, 2012 at 20:07:34 +0200: > 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.
For the record, I don't really object to the -1... the suggestion violates layering and hardcodes restriction where they don't quite belong. Its advantage is --- like stsp's suggestion --- not requiring a protocol version bump. And then there is ghudson's point, of course.
