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

Re: property names

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2001-03-31 03:07:48 CEST

Greg Stein <gstein@lyra.org> writes:
> On Thu, Mar 29, 2001 at 03:43:55AM +0000, Tripp Lilley wrote:
> > On Wed, 28 Mar 2001, Greg Stein wrote:
> > > I still want property names to use URLs. Presuming the IANA lists SVN: as a
> > > valid scheme and assigns it to us, then we can freely use SVN: however we'd
> > > like, and the prop names will (legally) be much shorter.
> Specifically, I'm seeking to get an entry into:
> http://www.isi.edu/in-notes/iana/assignments/uri-namespaces
> Once we are there, then nobody can bitch at us for using svn: as a property
> name prefix :-)

The IANA registration doesn't seem worth waiting for to me.

The legitimacy of IANA registration is only worthwhile if the increase
in allocation reliability is more helpful than the overhead of the
bureacracy is unhelpful.

- These conflicts aren't a serious problem to begin with. Even
  loosely coordinated groups can do a reasonable job keeping
  namespaces unique. Not perfect, certainly, but pretty good.
  Consider Unix libraries: when was the last time you couldn't use
  two libraries together because of naming conflicts? It does happen,
  certainly --- curses used to be a pretty serious namespace offender
  --- but it can be worked around. Since people have become aware of
  the issue, things have gotten a lot better. It's certainly not a

  So even if the IANA were perfect, it wouldn't offer us that much

- A central registrar isn't a robust design: allocation accuracy is only
  improved if everyone actually uses the same registrar. Any
  individual writing popular code but ignoring the registrar can
  introduce enough noise that the benefit goes away. And there are
  several reasons to expect people will blow off this registrar:

  - The registrar has pretty bad turnaround --- several months now,
  - I'm not convinced this registrar is even publicly recognized. I
    only see two schemes registered on the web page Greg mentioned,
    and both are Webdav schemes. If Greg Stein is the only
    co-operator in this game, kudos to him, but it makes the effort
    look kind of quixotic.

  - Certain influential software producing organizations have
    established histories of ignoring protocols and registrars.

  Of course, the version control world is not viciously competitive,
  the way the "instant messenging" world is, for example. People are
  pretty well-behaved.

- The "ownership" the registrar grants is kind of ill-defined.
  Clearly the "maintainer" is responsible for allocation within the
  prefix, but what happens if the project forks? Who gets the prefix?

I can think of plenty of examples of conventions like this that
weren't effective:

- The Java class naming convention --- net.collab.tigris and such
  --- is pretty roundly ignored.

- Even ethernet address allocation has had problems --- and ethernet
  addresses aren't even something people deal with directly, like
  class names.

(What's the history of TCP service numbers? I don't know of any real
problems there.)

This is a minor "tragedy of the commons" situation: if only everyone
would just co-operate, we could avoid annoying and pointless problems.
In these cases, I instinctively want to side with the co-operators ---
in our case, in favor of registration. But I worry that if we adopt
these long temporary prefixes, they will annoy enough people that we
will be effectively encouraging independent developers to blow off the
naming convention. So strict co-operation isn't really the best way
to protect the commons.

I suggest that, starting today, we simply use "svn:", and continue to
try to register the scheme with the IANA. I find the longer prefixes
irritating --- and the prospect of changing them in all existing
repositories when the "svn:" allocation does come through, even more
Received on Sat Oct 21 14:36:26 2006

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