Ben Collins-Sussman wrote:
> 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.
[...]
> So which is it? Is it part of the core system, or a contributed tool?
So, there is certainly some flexibility in the interpretation of the term
"core system", I think. When in a particular mood, the "core system" as I
see it doesn't include 'svnlook' and 'svnversion', because those things
aren't really required in a baseline Subversion deployment stack. Useful?
You betcha (svnlook far more so than svnversion). But required? Not
hardly. svnsync is the same way. Very useful, not required for version
control. It gets our seal of approval for The Right Tool To Use For
Repository Replication, sure. We like it so much we'll even build and
install it alongside our other binaries for you, and we promise that it will
work the very best it can, always and forever.
> 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!
Hrm. I think your perception of history is just optimistic. In the early
days, we basically threw everything that needed to be accessed from multiple
Subversion libraries into the public headers. It was ignorant and
short-sighted, but we did it. That's why wc-props and entry-props all live
there today, and you seem to agree that that is wrong. If you can admit
that there are glaring mistakes like having wc-props and entry-props in our
public headers files, how can you assert with confidence other things in
that same file were deliberately done with planned, good intentions? It's
entirely possible (probable, even) that having the revprops in those header
files was simply the exact same sort of mistake.
That said, having the revprops defined there *is* externally useful. I
would not be in favor of removing those from the public API, not because I
think that a header file should serve as human-consumed documentation for
the total set of Subversion's revprops (after all, many folks use Subversion
daily that have never read our source code, and need to know about such
things as how to modify svn:log on a given revision), but because they
provide convenience for folks *programming* against the API (note the
meaning of 'P' in that acronym) with an intent to interact with the
Subversion version control system.
Also, that it took you six years to find a use for this intentional design
choice should have at least caused you to pause and wonder why. Presumably
your hook script wants to create this list of acceptable "official" revprops
by parsing the svn_props.h file somehow. But what version of that file?
The one used to compile your Subversion server software? I mean, what
happens if the day before 1.4.0 releases, we add a new official revprop for
some reason. Are users of 1.4.0 stuck waiting for you to upgrade your hook
script to allow this new property? Do you instead generate the hook from a
cron job that reads HEAD of svn_props.h. Oh, but then you'd be allowing
*unofficial* official revprops into your repository. (You seeing the
problem here yet?)
Look, this entire discussion is laughable (and trust me, Garrett is actually
laughing). If you really feel strongly that svnsync's properties belong in
the svn: namespace, and belong in svn_props.h alongside other properties
that happen to be stored on revisions in Subversion repositories, I'm not
going to stand in the way of you making your life marginally better by
moving them into that file.
As a community, we could probably stand to carefully consider this idea of
the Subversion core system. I mean, honestly, why are svnversion and
svnsync in the main source tree while mailer.py and svnmerge.py (which also
uses custom properties) relegated to the tools/ directory. Simply because
they aren't written in C? These might be healthy questions to entertain.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Aug 18 08:32:00 2006