Garret Wilson wrote on Mon, Jan 23, 2012 at 21:03:30 -0800:
> On 1/23/2012 8:52 PM, Daniel Shahaf wrote:
> >In the past, people passed svn:log properties with embedded CRLFs
> >into that API --- which has been forbidden by some API doc or
> >another since 1.0.0, and is today caught and forbidden by
> >svn_repos__validate_prop().
>
> Huh! Yeah, actually a long time ago I remember complaining that had
> had used CRLFs and suddenly they weren't showing up in Subclipse, or
> something---my memory is hazy. But you know, coincidentally, just
> two days ago I thought of this when I entered a multi-line log entry
> in Subclipse---and it worked just fine! So I don't know where it is
> "forbidden". You can view the log history of https://svn.globalmentor.com/java/trunk/guiseframework/src/main/actionscript/com/guiseframework/platform/web/Guise.as
Short answer: multi-line != CRLF. Your log messages probably use bare
LF as the line terminator. (Check with 'propget --strict'.)
> to see what I'm talking about---it's public.
>
> But if you look into that, please let's start a new thread. I don't
> want my precious property name issue to get off track. :)
>
> >Is this materially different from the issue you are seeing ---
> >where as a consumer of the svn_ra_* API you used propnames that
> >you wouldn't have been able to set through the svn_client_* API?
>
> That sound analogous, yes.
>
> Garret
>
> P.S. My longer, overly verbose answer: Since I don't know the source
> code I can't say 100% if that's what I'm talking about, but yeah, it
> sounds analogous---I was allowed to do something over SVN+DAV that
> the clients don't allow me to do---and it wasn't because I was
> trying to break the rules, it was because I never knew I was
> breaking the rules and that my code wouldn't work across
> implementations. And then when I try to find out exactly what the
> rules are, it turns out there isn't even a specification and the
> "rules" are "go look and see what the code does..." etc.
So I am back to my previous suggestion of declaring
svn_prop_name_is_valid()'s current semantics canonical and calling that
function from svn_repos__validate_prop(). This should address your
point (ensuring consistency regardless of the protocol or API layer used
to access the server), though, of course, at the cost of breaking
svnsync of existing repositories that contain 'invalid' props.
And then the question is --- what do we tell people who have such
'invalid' props in their histories?
Received on 2012-01-24 06:22:50 CET