[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

request to clarify and improve Subversion property name specification

From: Garret Wilson <garret_at_globalmentor.com>
Date: Thu, 19 Jan 2012 14:20:55 -0800

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
), I created a scheme for encoding URIs inside normal Subversion
property names. An example is:


(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,

Received on 2012-01-19 23:21:43 CET

This is an archived mail posted to the Subversion Dev mailing list.