Garret Wilson wrote on Mon, Jan 23, 2012 at 20:34:56 -0800:
> On 1/23/2012 8:23 PM, Daniel Shahaf wrote:
> >Sounds, then, like you're asking not for extending the set of valid
> >propnames but for enforcing the existing conventions?
>
> No, the part about "...not asking for extending..." not a correct
> characterization of what I'm requesting. I tried to be clear in the
> first email:
>
> I therefore request:
>
> 1. That the restriction in JavaHL svn_prop_name_is_valid() be
> lifted to allow a Subversion property to be any valid XML name, and
Personally I don't see any obvious reason for deciding that svn property
names can be, of all things, "any XML name" --- the fact our wire
protocol uses XML need not ripple into our public API; ..
> 2. That there be a public specification that rigorously defines
> what makes a valid Subversion property name to prevent
> contradictory implementation issues like this in the future.
>
.. but +1 on deciding what a property name is and being consistent
about it. (with the caveat of not breaking existing repositories,
per r1235131)
> Sounds like you only zoned in on the "... if I'm voted down ... on
> lifting the restrictions ..." part. I really don't know how I can be
> plainer that what I listed above.
>
No, you can't, but thanks for spelling it out in a self-contained form.
> Garret
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().
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?
Received on 2012-01-24 05:53:55 CET