You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@newton.ch.collab.net> on 2001/03/28 21:36:05 UTC
property names
Greg -- a while back I added this to the end of svn_types.h:
-----------------------------------------
/* Defines for reserved ("svn:") property names. */
/* The fs revision property that stores the commit-log. */
#define SVN_PROP_REVISION_LOG "svn:log"
/* The propname *prefix* that makes a propname a "WC property".... */
#define SVN_PROP_WC_PREFIX "svn:wc:"
-----------------------------------------
But I notice that your versioned resource URL looks like:
http://subversion.tigris.org/props/ra/dav/local/version-url : /svn/repo/$svn/ver/3.1/A/mu
Nobody cares that this property has a really long name; but could we
at least make it use the "svn:" propname prefix? I thought we had
agreed to reserve the property namespace for svn-specific props this
way.
Re: property names
Posted by Karl Fogel <kf...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I set up the long name quite a while back, under the assumption that the
> names are URLs to ensure uniqueness. I avoided SVN: because we have not been
> assigned that URL scheme by the IANA. Last week, I resent my query to the
> IANA for assignment of that prefix.
>
> 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.
We can (and should) freely use it before the IANA gets around to
noticing.
Unless you're proposing that the IANA could take any arbitrary amount
of time, and we'd just have to use long URLs until then? :-)
Are we *really* risking anything by reserving a short namespace prefix
that people can remember, as opposed to a long URL prefix that happens
to have been approved by the IANA? I think not. Meanwhile, the long
names are inconvenient for testing, debugging, and inspecting.
You can put "svn:" on the front of the URL, if you want an even higher
probability of uniqueness. :-)
-K
Re: property names
Posted by Sam TH <sa...@uchicago.edu>.
On Fri, Mar 30, 2001 at 08:07:48PM -0500, Jim Blandy wrote:
> Greg Stein <gs...@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.
<long snip>
I'm still puzzled as to why people don't seem to want to consider my
suggestion of using URNs for this purpose. The major drawback to
using a URN is that it is not (currently, and for the forseeable
future) derefernceable. But no property names in Subversion need to
be. So what would the problem with
urn:svn:prop.name.here
be?
sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dynds.org/decss
Re: property names
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Greg Stein <gs...@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
show-stopper.
So even if the IANA were perfect, it wouldn't offer us that much
benefit.
- 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,
right?
- 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
so.
Re: property names
Posted by Greg Stein <gs...@lyra.org>.
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 :-)
> I was looking around to see if there was a short URL scheme for
> "experimental" schemes, but there doesn't seem to be. However, in case you
> haven't already read them, I recommend the RFCs listed below. If you
> -have- read them, then I'll shut up :)
I haven't read them; was unaware of them. Thanks for the pointers! I'll take
a look.
> RFC 2717 - Registration Procedures for URL Scheme Names
>
> Mentions "alternative" URL scheme trees, but doesn't specify any
> existing atlernatives to the IETF scheme tree
The IANA is the official registry. IETF is mostly about protocols and does
not manage registrations and assignments.
But I'll go read that RFC...
> RFC 2718 - Guidelines for new URL Schemes
>
> Has a bunch of good info on designing URL schemes, including some
> tasty bits I didn't realize, such as "//" as the first characters
> after the : being reserved for schemes that are hierarchical...
Hmm. Neat. A must read.
> I did find an I-D that proposes a "vnd" namespace (ie: "vnd.tigris.svn:"),
> but it's just an I-D, and it looks like it might be going stale soon. I
> didn't hear anything announced about it after the last IETF meeting.
That would be nice.
Along similar lines, when we ship a diff up to the server, I will use
application/vnd.svn-svndiff for the MIME type. Probably build recognition
into the server for that and application/svndiff for the eventual point
where we get a formal IANA MIME type registration.
Thanks for the pointers!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: property names
Posted by Tripp Lilley <tl...@perspex.com>.
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.
I was looking around to see if there was a short URL scheme for
"experimental" schemes, but there doesn't seem to be. However, in case you
haven't already read them, I recommend the RFCs listed below. If you
-have- read them, then I'll shut up :)
RFC 2717 - Registration Procedures for URL Scheme Names
Mentions "alternative" URL scheme trees, but doesn't specify any
existing atlernatives to the IETF scheme tree
RFC 2718 - Guidelines for new URL Schemes
Has a bunch of good info on designing URL schemes, including some
tasty bits I didn't realize, such as "//" as the first characters
after the : being reserved for schemes that are hierarchical...
I did find an I-D that proposes a "vnd" namespace (ie: "vnd.tigris.svn:"),
but it's just an I-D, and it looks like it might be going stale soon. I
didn't hear anything announced about it after the last IETF meeting.
--
Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
"Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>
Re: property names
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Mar 28, 2001 at 03:36:05PM -0600, Ben Collins-Sussman wrote:
>...
> Nobody cares that this property has a really long name; but could we
> at least make it use the "svn:" propname prefix? I thought we had
> agreed to reserve the property namespace for svn-specific props this
> way.
I set up the long name quite a while back, under the assumption that the
names are URLs to ensure uniqueness. I avoided SVN: because we have not been
assigned that URL scheme by the IANA. Last week, I resent my query to the
IANA for assignment of that prefix.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/