Re: maintaining a list of svn: revprops

Ben Collins-Sussman wrote:
> I'd like to move the svn:sync-* revprop definitions from within
> svnsync/main.c to the public svn_props.h file. Here's why:
>
> We need a single registry for all svn: revprops.
>
> - Someday the svn codebase may get large enough that one part may
> start accidentally stomping on another's revprops. It's not good
> to scatter the definitions.

I think there are a couple of overlapping issues here.

There's the primary problem -- the properties currently consuming the
svn:sync-* namespace should not be. They belong in the svnsync: namespace,
because no part of Subversion-the-core-libraries-of-a-cool-version-
control-system needs to care about about those properties. In fact, this is
how they were originally defined, but I believe Garrett conflated the "make
svnsync part of the Subversion distribution" with the "make svnsync's
implementation details a part of Subversion-as-a-whole's details".

Now, because of the primary problem, you (perhaps rightly) perceive that
Subversion's carved-out niche of the property namespace is being documented
in multiple places. I think that's a fair concern.

I say we fix the former problem, and now you're left with no reason to be
concerned that Subversion's properties are being defined in multiple places.

> - While API consumers know that it's illegal to invent new svn:
> props, it's useful for them to see the exact list of 'official'
> svn: props.
>
> (In particular, my itch here is that I'm writing a
> pre-revprop-change hook program which wants to enforce that
> *only* the official ten svn: revprops are ever tweaked.)

That's sorta fair, too. But again, I think you aim to fix the wrong problem.

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.
It's possible that you might have to read its documentation, and actually
hard-code the property names you wish to permit in your script. A program
*is* allowed to make promises and have contracts with its users that exist
outside of C library header files.

> - The public svn_props.h has always been our registry until
> recently. I'm simply maintaining this registry by sucking in
> svn:sync-* props out of svnsync/main.c.

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.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand