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

xml config (was: Re: CVS update: ...)

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-14 20:23:52 CET

Urk. Euh... we've been through this before. I forget whether the previous
round was XML and/or lisp-y syntax. I'll emphatically state again: if a file
is expected to be edited by a user (a human) than lisp-y is Bad and XML is
Worse.

Sure, tools like XML and lisp-y (and in turn, so does the SVN code), but a
human is not a tool. Humans deal with .INI style okay because they are
simply option=value lines. As soon as you give them structure (like lisp-y
syntax), then they get a headache. Give them structure and hard syntax
requirements (like XML), then their head just blows up.

I would hope that we have zero client-side config, but I'm also realist
enough to know we will :-) ... and for that config, it should be .INI style
or something similarly brain-simple.

Cheers,
-g

On Mon, Nov 13, 2000 at 04:00:02PM -0600, Karl Fogel wrote:
> Oh yes -- of course, the diff and patch programs have to be settable
> at run time. But we still need to have a default set at build time,
> so we're not off the hook.
>
> What do others think about XML config files?
>
> -K
>
> Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> > But seriously, we need to start thinking about /etc/svnrc and ~/.svnrc
> > (and Win32 equivalents) for the client library. SVN_CLIENT_DIFF and
> > SVN_CLIENT_PATCH are definitely candidates for run-time configuration,
> > with compile-time defaults.
> >
> > Could we write the config files in XML?
> >
> > (The server gets configured via Apache's config files, right?)
> >
> >
> > --
> > Brane �ibej
> > home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
> > work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
> > ACM: <brane_at_acm.org> http://www.acm.org/

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:14 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.