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

Objection to change in svn_depth_t component naming (r21067) (was: Re: [PATCH] Infrastructure changes for incomplete directory support.)

From: Max Bowsher <maxb1_at_ukf.net>
Date: 2006-08-14 12:24:27 CEST

C. Michael Pilato wrote:
> Peter Samuelson wrote:
>> [Karl Fogel]
>>> Well, I don't really know how widespread the WebDAV concept of depth
>>> is using the WebDAV names. I had thought "depth zero" and "depth
>>> one" and "depth infinity" *were* pretty much how the world refers to
>>> these different depth behaviors... Or at least, that those were the
>>> closest thing we have to standard terminology.
>> LDAP has the same concept, where a search has a "scope" of either BASE,
>> ONELEVEL or SUBTREE. Apparently LDAPv3 also has CHILDREN, I'm not sure
>> how that's different.
> There ya go, Karl -- names for your marshaled depths: "base", "onelevel",
> and "subtree". Also, you could use "exact" instead of "base" -- they are
> synonyms in LDAP-land.
> (CHILDREN is just SUBTREE minus EXACT.)

Sorry, I wasn't following this thread and didn't comment before - I've
just noticed that such a change was committed in r21067.

I would like to object on the grounds that the zero/one/infinity naming
scheme is far more intuitive than the LDAP names.

This isn't just a reflexive action the change on the first time
encountering the LDAP names - I've run into them before, and found them
unnecessarily confusing about the precise concepts they refer to.

Whilst "onelevel" is reasonable, neither "base" nor "exact" communicate
their concept to me as clearly as "depth zero". Ditto for "subtree",
which makes me think of selecting just a particular subtree of nodes
from underneath the object it is being applied to, not entire tree
rooted at the reference object.


Received on Mon Aug 14 12:25:15 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.