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

Re: property names (was: Re: grumble, grumble)

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-21 00:13:03 CET

On Wed, Dec 20, 2000 at 03:14:17PM -0500, Greg Hudson wrote:
>...
> > Can somebody give a rational reason for not using URIs for prop
> > names?
>
> I think it's a heavyweight solution to a fairly small problem.

"heavyweight" is an arguable term to apply :-) I see a URI as an opaque
string. Things such as "prop-name" are also opaque strings. One is a bit
longer, and has unique-ness properties. It doesn't have to resolve in a web
browser, and it doesn't have to follow any particular organization (beyond
URI requirements of "scheme:scheme-specific-stuff").

> We
> don't use URIs for our C function names, for instance; we assume the
> "svn_" prefix will be good enough.

I'd say that we don't use them because our tools don't support it. :-)

Look at the Java world. They use URI-like naming for their stuff. Consider
"org.apache.slide.*" vs "com.ibm.*". People are using their domain name as a
unique identifier, much like a URI does.

Within C code, we *attempt* to be unique by using special prefixes (ap_ for
Apache, apr_ for APR, svn_ for Subversion). But we don't really have any
guarantee. Look at the C++ "namespace" thing -- that is an attempt to add
more uniqueness to the names.

In other words, programmers are *striving* for the uniqueness of URIs in
their naming, but the tools only go partway. Out-of-band "policy" assists in
this (e.g. a policy is the Java naming, or selecting a prefix).

> Property names do get presented to
> the user (they don't have to be presented to the user exactly as
> stored, but what is presented to the user needs to be just as unique
> as what is stored), and presenting a URI is both confusing and
> obfuscating--confusing because the user might think the URI would mean
> something to a web browser, and obfuscating because there's a lot of
> crud in there besides the interesting part of the property name.

That is a UI issue, not a reflection of problems in the underlying
mechanics.

Consider the two properties that libsvn_ra_dav stores into the local
prop-store:

  http://subversion.tigris.org/props/ra/dav/local/activity-url
  http://subversion.tigris.org/props/ra/dav/local/version-url

That is quite a mouthful, but I can guarantee that it won't conflict. I tend
to agree that it is also a bit hard for users to deal with. But *only* if
you make them spec the whole thing. Simple answer? Just show the last part:

$ svn propget some/dir
activity-url = http://www.lyra.org/repos/$svn/act
version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
version-url = I'm a dumbass

$ svn propget -v some/dir
http://subversion.tigris.org/props/ra/dav/local/activity-url = http://www.lyra.org/repos/$svn/act
http://subversion.tigris.org/props/ra/dav/local/version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
http://www.dumbass.org/svnprops/version-url = I'm a dumbass

$ svn propget some/dir activity-url
activity-url = http://www.lyra.org/repos/$svn/act

$ svn propget some/dir version-url
Warning: multiple name matches
version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
version-url = I'm a dumbass

$ svn propget some/dir "*subversion*/version-url"
version-url = http://www.lyra.org/repos/$svn/ver/37/some/dir
[gjs: an example of "globbing" for prop names]

$ svn propset some/dir activity-url http://this/will/break/things
[gjs: this could update the existing prop when found]

$ svn propset some/dir my-prop foobar
$ svn propget some/dir my-prop
my-prop = foobar

$ svn propget -v some/dir my-prop
http://subversion.tigris.org/svnprops/user-named/my-prop = foobar

$ svn propset some/dir version-url blather
Error: multiple name matches -- a more specific name is required

etc.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

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