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