The files offer administration advantages as well as versioning advantages.
They allow system-wide configuration to be more easily shared among multiple
computers. They allow you to quickly copy directories from one computer to
another in order to replicate configuration information. They make it
easier to remove all traces of an application without having weird
configuration junk accumulate on the computer. They allow multiple
versions/copies of the application to exist at once and not share
system-wide configuration with each other. At a few conferences I attended
last year, the registry has actually been compared to "hell" from an
administrative standpoint (it's the technology of a centralized
configuration repository that's the interesting part of it).
The "goofy little files" problem is solved by putting them in standard
locations (and the comment about users wanting to put them in different
places is silly... if they want to, they probably have good reason to; and
if it bothers you that much you just don't let them).
ACK! Are those ini files! *sobs quietly at his desk* With Windows moving
to (and OSX already at) using XML as the container for configuration (even
if the hierarchial assumptions tend to be weak on both platforms), and Unix
never having wanted to touch ini files, how did Subversion end up choosing
ini files as it's way of storing configuration files?
<quote src="http://www.elementkjournals.com/asp/0201/asp0211.htm">
So why use XML files? In our previous article about INI files, we offered a
number of advantages of using these files over an alternative repository
like the system registry. Among these benefits were that you can include
comments, you can store them in common locations and share them among
applications, and they're more stable and self-contained than the registry.
All of these apply to XML files as well, plus XML offers some new advantages
of its own.
XML is poised to become the lingua franca of Web-based data access and
manipulation. The past few years have seen more and more widespread adoption
of XML-based file formats for almost every imaginable use. Also, because XML
is a W3C standard, you can be sure that it isn't going anywhere. In fact, as
part of its XP and .NET initiatives, Microsoft itself is transitioning into
the use of XML configuration files instead of INI files. In ASP .NET, you'll
see a wealth of native support for XML, which is a good reason to begin
using it now.
Another advantage of XML is that you can use XSLT to manipulate and
transform XML files into a variety of different representations. INI files
offer no such capabilities. And finally, the toolbox for using XML is much
broader, more powerful, and more flexible than for simple INI text files.
For example, you'll see shortly how to use XPath expressions to gather
together and process disparate pieces of an XML file.
</quote>
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Branko Čibej" <brane@xbc.nu>
To: <dev@subversion.tigris.org>
Cc: "Karl Fogel" <kfogel@newton.ch.collab.net>
Sent: Tuesday, March 26, 2002 3:24 PM
Subject: Re: config files on Windows
> I think I'm finally seeing a light at the end if this tunnel. On
> Windows, the Registry is obviously the preferred location for
> configuration data. Typically, only developers will want to use a file
> (because editing the registry by hand is a royal pain). So I'd suggest
> we load the configuration in this order:
>
> * System-wide
>
(HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\{config,proxy,...}
> * User-specific
> (HKEY_CURRENT_USER\Software\Tigris.org\Subversion\{config,proxy,...}
>
> Then we look at the options in the config "file" to see if there are
> more files to load. I'd even suggest a windows-specific section in the
> config file, like this:
>
> [windows-cruft]
> use-config-dir = C:/my-home-dir/.subversion
>
> (or rather, that would be
>
HKEY_CURRENT_USER\Software\Tigris.org\Subversion\config\windows-cruft:use-co
nfig-dir)
>
> Then, if that option exists, try to load the file from that directory.
>
> I'll code this up if people agree.
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 26 23:27:50 2002