Okay, let's ask some basic questions here. :-)
What is the purpose of supporting a config dir/files under Windows?
The only reason to support file-based (non-Registry) config, as far as
I can see, is so that people who need to use the same configuration on
multiple machines can keep their .subversion/ dir under version
control. Then they can keep checked out copies on various machines,
including Windows machines.
However, so far the only person I've seen advocate this is someone who
doesn't actually use Windows much (me). Meanwhile, the Windows users
seem to mostly prefer the Registry, though they're still contributing
their expertise to get configuration files working, mostly to humor me
I think. :-)
If all Windows users think the Registry is sufficient, then I don't
see much point going through contortions to figure out all possible
for a file-based configuration area.
Thoughts?
Hontvari Jozsef's suggestion of looking at the APPDATA variable below
means that even if we find a configuration, it would be
system-specific, not user-specific (and the USERPROFILE var is even
less likely to exist ... And the more vars we check, the less
consistency we have when answering the question "Where are my config
files under Win32?"!)
On a semi-unrelated note, the Registry needs to get initialized at
install time (or run-time, though install makes more sense); Mike
Pilato and I are working on that.
-Karl
Hontvari Jozsef <hontvari@solware.com> writes:
> 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 Tue Mar 26 19:57:56 2002