By the lack of response am I to conclude that rigorous specification and
client interoperability are not considered high priorities on this list?
Garret
On 1/19/2012 2:20 PM, Garret Wilson wrote:
Summary: There seems to be no public specification (other than the
source code) on what makes a valid Subversion property name.
Subversion property name validation is implemented differently on
various clients, including "official" clients. I request that the
Subversion property name specification be clarified and improved, and
I will help in whatever capacity I'm needed and allowed.
Several years ago I created my own WebDAV client to interface with
Subversion over SVN+DAV. Because Subversion properties do not honor
custom namespaces (I found this out through trial-and-error; see
http://www.garretwilson.com/blog/2008/04/08/subversionpropertynamespaces.xhtml
), I created a scheme for encoding URIs inside normal Subversion
property names. An example is:
http·3a·2f·2fpurl.org·2fdc·2felements·2f1.1·2ftitle
(Note the use of the middle dot character, which is a perfectly valid
XML name character.) This worked just fine on SVN+DAV all these years.
It also worked just fine reading from and writing to repositories
using SVNKit. Unfortunately, a few days ago I tried to add such a
property using TortoiseSVN and later Subclipse; the JavaHL layer
complains of a "Bad property name."
With a little help from the TortoiseSVN mailing list and the
Subversion Users mailing lists, it turns out that the JavaHL API says
the following for svn_prop_name_is_valid(): /For now, "valid" means
the ASCII subset of an XML "Name"./ The source code of this method
requires property names to be a (alpha/colon/underscore) character
followed by any number of (alpha/number/minus/dot/colon/underscore)
characters.
I would like to point out the following items for consideration:
* There is no public specification that I know of regarding what
makes a valid Subversion property name.
* The source code comments to svn_prop_name_is_valid() say "for
now", indicating that there has been no final decision on what
makes a valid property name.
* SVN+DAV has for years been allowing Subversion property names to
be anything that is a valid XML name; SVN+DAV shouldn't have
different standards than JavaHL, but surely because of this
discrepancy there must be data in the wild (e.g. mine) created via
SVN+DAV that adheres to these looser standards.
* SVNKit reads and writes UTF-8 encoded Subversion property names
just fine if they are valid XML names, even if they don't meet the
requirements of JavaHL's svn_prop_name_is_valid() method.
* TortoiseSVN reads these UTF-8 encoded properties names just fine,
even if they don't meet the requirements of JavaHL's
svn_prop_name_is_valid() method.
* Subclipse reads these UTF-8 encoded properties names just fine,
even if they don't meet the requirements of JavaHL's
svn_prop_name_is_valid() method.
In light of all of these considerations, as far as I can tell the only
thing that svn_prop_name_is_valid() accomplishes by restricting
property names to ASCII is that it prevents me from using the property
names I want to use, which I have been using for years on SVN+DAV; for
which SVNKit works just fine; and for which TortoiseSVN and Subclipse
read just fine (but cannot write because of JavaHL's arbitrary
restriction).
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
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.
I volunteer to change the code, update specifications, or whatever
else I am given permission to do in order to accomplish the above two
outcomes. Until then, I'm sitting here stuck with gigabytes of data
that I can't update locally through normal Subversion tools.
Thanks for your consideration,
Garret
