On 8/17/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> There's the primary problem -- the properties currently consuming the
> svn:sync-* namespace should not be. They belong in the svnsync: namespace,
I agree, this is a fundamental issue that needs to be resolved before
we can really talk about anything else. I could see the argument go
either way for this.
If svnsync were a third-party tool written totally independent of
subversion, then sure, I would expect it to use its own property
namespace, just like svk does. But I got the general vibe that
svnsync has been promoted to an official subversion tool, just as
official as svnserve, svnadmin, svnversion, and so on. By "official",
I mean, "considered a core part of the overall subversion version
control system, and directly supported by the subversion developer
community" -- just like all of the svn* binaries are. If that's
really the case, then I believe it *should* be using the svn:
namespace. The svn: namespace is for use by the overall system.
It sounds, however, like you don't agree with this classification,
that you consider svnsync to be just another tool which happens to be
distributed with subversion's source code for convenience's sake. If
that's really your position, then we should move it into contrib/ or
tools/, right? (And in that case, yes, it should use its own private
property namespace.)
So which is it? Is it part of the core system, or a contributed tool?
> I hate to say so, but I kinda get the sense that at the core of it, you're
> annoyed that you can quickly and programmatically determine the full list of
> properties you want your hook to allow, and that's tainting your vision here
> a bit. I mean, say that Garrett had *not* brought svnsync under the
> Subversion umbrella. Not every piece of software has a "header file" that
> you can conveniently parse to determine the Subversion properties it uses.
I agree with you. I completely understand that not all software makes
it convenient to programmatically parse its artifacts, and I
understand that it's under no obligation to do so.
What I'm annoyed about is that for six years I've been under the
impression that we've *deliberately* been declaring svn: revprops in a
public header file as a "niceness" to third parties. Of course it's
not required; of course I can live without it; I'm just really
surprised that you're saying that this perk has either not existed all
along, or if it has, it shouldn't continue to exist. I've always
thought it was an intentional design choice... and hey, wow, isn't it
cool that I finally get to make use of it!
So I think that independent of svnsync's classification and property
use, we should come to an agreement on our policy here. Are we going
to export a friendly list of revprops to the world, or not? What are
the arguments for or against such a policy? To me, this is a perk
we've always had, and should continue to support. I sounds like
you're against this idea, though I'm not entirely understanding why.
Maybe you can elaborate?
> Hrm, this is weak. We have made a slew of mistakes in the past with respect
> to our public API, but that is no reason to propogate the madness. Present
> alongside legitimate interesting-to-third-party properties in this
> "registry" are the wc-props and entry-props, none of which *should* be
> meaningful outside the black box of Subversion core libraries. And yet
> there they sit. We have error codes in svn_error_codes.h that are specific
> to our command-line client program, and (especially as described by their
> default error strings) serve no purpose outside of that restricted scope.
> We have only very recently started talking about creating a private header
> file area for housing things that need to be grokked across multiple
> Subversion libraries, but not deemed part of our third-party-consumable APIs.
I agree with you; I can't comprehend why wc-props or entry-props
would be useful to third parties. Same with certain error codes. I
very much support the push to a private-header for things that need to
be interally shared across subversion libraries.
That said, this isn't a black and white issue. Some things should be
hidden, and some should not. It sounds like you're arguing that
*everything* that can be hidden, should be hidden. And I'm saying,
hey, a definitive list of svn: revprops shouldn't be hidden; they're
actually useful to the outside world. Can't we find a middle ground
here? Evaluate each thing inpendently, decide what should be hidden,
and what shouldn't?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 18 04:09:23 2006