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

Re: svn commit: rev 1563 - trunk/subversion/include trunk/subversion/libsvn_subr trunk/subversion/clients/cmdline trunk/subversion/libsvn_ra_dav

From: Hontvari Jozsef <hontvari_at_solware.com>
Date: 2002-03-22 02:16:32 CET

At 2002/03/21 17:13 -0600, Karl Fogel wrote:
> Hontvari Jozsef <hontvari@solware.com> writes:
> > The correct behaviour would be to store these configuration files in the
> > "Application Data" folder, under a Subversion subdirectory (or
> > Subversion\.configuration). That directory is specific to a user. There
is
> > even an environment variable named "APPDATA" pointing to the
"Application
> > Data". This is true on Windows 2000.
> >
> > If - on a specific Windows version - there is no such environment
variable,
> > then IMHO a default directory should be used under the directory of the
> > svn.exe.
>
> Okay, thanks! Let me spell out my understanding so far, just to make
> sure:
>
> Under Windows (just Win 2000, or all Win32?), we will continue to
> fetch configuration data from the Registry first. After any Registry
> data is read, we'll merge in data from config files. We'll find the
> config files in a config directory, which we'll locate like this:

Registry works on all win32 windows. However special folders are very
different in each windows version.
(Personally I would not implement retrieving configuration data from BOTH
registry and files)

Looking for APPDATA is correct, it might be supplemented using the
USERPROFILE as a backup. But using the current directory will not work (it
is not really deterministic), instead we should use the directory of the
executeable. If you use the registry too, IMHO even all of these steps are
not entirely necessary (I would stop at APPDATA, and if that is not set,
then I would say that there are no configuration directory/files, period.)
The whole process:

1. First look for the APPDATA environment variable as it is already in the
code sample. That will only exists on Windows 2000 and upper.
2. If APPDATA is not set, then look for the USERPROFILE environment
variable. That exists from Windows NT 4. If found then use the directory
%USERPROFILE%\Application Data. This will correspond to APPDATA. If there is
no "Application Data" subdirectory then create it.
3. If nothing is set then use the directory of the current executable. That
is not the same as the current directory, the latter can be anything. I know
two ways to get that directory: either by using the 0. argument of the main
function which cointains the full path of the executeable or the
GetModuleFileName function. If you want I can make you a small code snippet
which uses GetModuleFileName.

>
> char *appdata_dir = getenv ("APPDATA");
>
> if (appdata_dir)
> {
> svn_config_dir = apr_psprintf
> (pool, "%s\\Subversion\\.configuration", appdata_dir);
>
> if (svn_config_dir does not exist)
> {
> svn_config_dir = apr_psprintf
> (pool, "%s\\Subversion", appdata_dir);
> }
> }
> else /* no APPDATA dir, so look in current working directory */
> {
> svn_config_dir = ".\\some-default-dir";
> }
>
> Within that dir, the files will have the same names as they do in
> ~/.subversion/ under Unix -- that is, `proxies' etc.
>
> Should some-default-dir be "Configuration" or ".configuration", or
> something else entirely?

Configuration is better, as Alan wrote.

(Remark Microsoft recommends the using of SHGetFolderPath API function
instead of environment variables. This theoretically works everywhere, but
practically this function comes only with win2000 and upper, and only in
service packs for previous versions - you can also redistribute the dll, if
you have a setup program which is able to do that...).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 22 02:18:13 2002

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.