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

Re: request to clarify and improve Subversion property name specification

From: Garret Wilson <garret_at_globalmentor.com>
Date: Mon, 30 Jan 2012 06:31:19 -0800

On 1/29/2012 11:26 PM, Daniel Shahaf wrote:
> ...
>
> - Publish your "properties migration" code for others to reuse.

Done:

https://svn.globalmentor.com/java/trunk/globalmentor-marmot/src/main/java/com/globalmentor/marmot/repository/svn/svnkit/SVNKitSubversionRepository.java

You'll need the related projects; check out everything here and build
with Maven (the "globalmentor-marmot" project POM indicates which
projects are required):

https://svn.globalmentor.com/java/trunk/

> [1] If you answer "In a specification" I'll ask how it would relate to
> the existing API docs.

The mythical "Subversion Specification" is a completely different animal
than an API specification. After all, there can be (and are) different
APIs (e.g. DAV+SVN, JavaHL, SVNKit). The APIs should all follow the
"Subversion Specification", which is agnostic to any API. One of the
biggest disconnects in the Subversion community seems to be this idea
that some source code comments of an API substitutes for a specification
of Subversion itself---the framework.

Think about it in terms of XML: There is a specification for the XML
API, the DOM: http://www.w3.org/TR/DOM-Level-3-Core/core.html . However,
the API specification still depends on the definition of what XML itself
is (e.g. what constitutes an XML name, what types of nodes there are,
what types of children nodes can have): http://www.w3.org/TR/REC-xml/ .
Many people I've communicated with in the Subversion community seem to
think, by way of analogy, that the DOM specification (just in code
comments) is all that's needed---there's no point in taking the time to
write the specification for XML itself. I wholeheartedly disagree.

Garret
Received on 2012-01-30 15:31:59 CET

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