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
>
Received on 2012-01-23 16:14:04 CET