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
Received on 2012-01-23 21:09:05 CET