On 1/23/2012 11:50 AM, Philip Martin wrote:
... The situation is that the low level svn_fs.h API allows property names to be any null-terminated C string. The intermediate svn_ra.h API imposes restrictions because only XML names can be marshalled over http:, I think svn: allows anything. The high level svn_client.h API restricts names to a subset of ASCII and thus avoids passing anything the RA layers cannot handle. You want to relax the svn_client.h API to allow XML names. Strictly speaking I suppose a 3rd party RA implementation might only support the svn_client.h subset, but I don't know of any other RA implementations.
Although I want to relax the restrictions for my own personal reasons (i.e. to make my code work over JavaHL with repositories with which my code has worked for years over SVN+DAV), what is even more important to me is consistency. It makes no sense to me if a client has different naming rules based upon the method of access to a repository.
So if I'm voted down (I'm just speaking proverbially here---I don't even know if I would have "voting rights") on lifting the restrictions, I would want to /impose/ restrictions on svn: and http:. Everyone should play by the same rules. If the same rules would have been in place from the beginning, I wouldn't even /be/ in the situation I am now, because at least SVN+DAV would have rejected the property names I was using. I had no idea they would stop working once I moved to accessing my repository locally using JavaHL-based clients.
So yeah, I want to relax the svn_client.h API on what makes a valid property name. But even more than that, I want consistency across all clients. And even more than that, I want a specification that says what the rules are...
Anyway, I don't want to risk over-arguing this. It should be plain what I'm asking at this point---someone just let me know if my request will be granted.
Cheers, Garret
