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?
