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

Re: defining 'core' subversion

From: Karl Fogel <kfogel_at_google.com>
Date: 2006-08-22 08:32:02 CEST

"Ben Collins-Sussman" <sussman@red-bean.com> writes:
> On 8/19/06, Eric Gillespie <epg@pretzelnet.org> wrote:
>> > Stuff in tools/ *is* in the main source tree, and is a supported part
>> > of Subversion.
>> make install still doesn't install them, right? That makes
>> tools/ a ghetto. I feel the same way about the bindings.
> Ooh. Now that's an interesting criteria. I have to admit, the fact
> that all the C-language svn* binaries get installed makes them feel
> much more 'official' than anything in tools/.

It would be nice to have a simple, clear definition. But I don't
think things are that easy here.

For example, a hook script might be officially supported, but we can't
install it automatically, because not only do we not know where the
repositories are, but even if we did (say, by installing said hook at
'svnadmin create' time), we wouldn't know what config options to fill
out to make the hook behave usefully.

Solving all those issues would basically mean wrapping Subversion in a
friendly administrative interface, which would be a project about as
large as Subversion itself :-).

That's why I think this way:

   1) Anything we install via 'make install' is "official".
   2) Some things we don't install are also "official" (see tools/).
   3) Other things we don't install are not "official" (see contrib/).

Now, there could be more things in (2). For example, svn_load_dirs.pl
could get installed by default. We just happen not to do that, for
historical reasons, not because our plan for world domination tells us
not to install it or anything.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 22 08:33:38 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.