Some things you could still do include
- Make _concrete_ suggestions about what needs to be documented where.
- Send a patch to svn_repos__validate_props() (and make your case that
it should be applied)
- Send a patch to the book
- Send a patch to the relevant API docs
- Publish your "properties migration" code for others to reuse.
 If you answer "In a specification" I'll ask how it would relate to
the existing API docs.
Garret Wilson wrote on Sun, Jan 29, 2012 at 09:25:40 -0800:
> The story ends this way: I've spent days writing migration code
> which traverses the gigabytes of my various repositories and
> converts legacy property names (the ones I've been using for years
> over DAV+SVN, not knowing they were invalid in JavaHL) to "valid"
> Subversion property names (according to the source code; there exist
> no public specifications).
> Creating this throwaway migration code was many times over more work
> than it would have been simply to loosen slightly the restrictions
> in the Subversion client source code to be more liberal with
> property names. On the other hand, writing this migration code was
> many times over /less/ work than all the time and effort I would
> have spent trying to get permission (or even interest) in modifying
> the Subversion source code, or even to publish a specification.
> I did get a bit of constructive discussion to at least understand
> the issue, and I appreciate the "+1" I received for the concept of
> creating a specification and making property name requirements
> consistent across clients. But I have been given no authority to
> create any specification or modify any code, and I suspect that
> three years later when I check back on the issue, everything will be
> in the same situation it is today. In addition, there exists the
> issue of legacy data created over DAV+SVN not compatible with other
> clients. But with loads of work on my plate, and having migrated my
> own data, I'm afraid I must be pragmatic: it's not my problem
> I love Subversion, and I wish the Subversion development community the best.
> On 1/23/2012 7:17 AM, C. Michael Pilato wrote:
> >On 01/23/2012 10:13 AM, Garret Wilson wrote:
> >>By the lack of response am I to conclude that rigorous specification and
> >>client interoperability are not considered high priorities on this list?
> >Conclude what you will. But a more accurate conclusion might be "I've only
> >allowed a single 'business day' for discussion of this thread, so perhaps I
> >should wait a bit longer for folks to chime in." I can't speak for others
> >of course, but I only *just* got around to reading your original post a few
> >minutes before this your follow-up hit the list.
Received on 2012-01-30 08:28:22 CET