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

Re: Objection to change in svn_depth_t component naming (r21067)

From: Karl Fogel <kfogel_at_google.com>
Date: 2006-08-14 18:06:10 CEST

Max Bowsher <maxb1@ukf.net> writes:
> 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.

I'm sure this seems trivial to many people, but it's worth getting
these names right (and doesn't hold anything else up, as they're easy
to change at any time).

If we say "tree" instead of "subtree", does that address that
particular issue, Max? It's still close enough to the LDAP original
that we'll get the benefit of familiarity.

"Base" vs "zero" is a little tougher. I personally don't find either
one much more intuitive than the other, and would like not to differ
unnecessarily from *some* standard name -- in this case, the LDAP
name, for consistency with the "onelevel".

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 14 18:07: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.