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.
Received on 2012-08-19 18:24:01 CEST