Eric S. Raymond wrote:
> David Glasser <glasser_at_davidglasser.net>:
>> My advice: what do you mean when you say that it does not make sense
>> to ship it as a standalone project?
>
> It's so tied to the internals of Subversion that I think I'd prefer to
> have it co-located with Subversion. And there's some risk that if I create
> it as a standalone project, people simply won't *find* it. One corollary of
> projects-are-cheap is that learning what's relevant to what you want to do
> can be difficult. The problems of superabundance...
>
> Yes, Google searches mitigate the problem, but they don't entirely
> solve it. The tradeoff I'm choosing, consciously, is to go through
> your bureaucracy in order to make the tool more easily discoverable to
> those most likely to need it. In this *particular* case the choice is
> esier because I'm pretty sure that if I were to come to this dev list
> in the future and said "Hey, I need commit access now to tweak
> svncutter" I'd get it without fuss.
>
> That said, I mostly agree with your more general point. Project creation abd
> hosting are cheap. We should behave more like that's true than we often do.
As one of the svn developers, I'm more of the mind of Eric than David here, so
don't agree with the Subversion developers that want to see contrib phased out.
I do think there's value in having one central place to store smaller tools than
having to go look for them elsewhere. It is nice to go to contrib/ or tools/ to
look and see if there's a tool you need or could use. If each of the tools were
a separate package, then as a newer Subversion developer/administrator, you may
not even find out that a particular tool is useful, (say case_insensitive.py to
protect yourself from case issues on Windows and Mac clients).
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2405198
Received on 2009-10-08 19:24:29 CEST