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

%APR_ICONV_PATH%: SVN vs. TSVN (and other related) on Windows

From: Jostein Chr. Andersen <jostein_at_josander.net>
Date: 2004-03-30 14:03:18 CEST

Hi,

Both Subversion (at least the installer) and TortoiseSVN sets the
environment variable %APR_ICONV_PATH% for their own paths. I just
installed TSVN and do now have TSVN's %APR_ICONV_PATH%.
The same thing happends the opposite way if Subversion is installed as
the last one.

I can imagine that this can make trouble for us. What can happend if one
of them already is installed (and working well) and another one is
installed with bogus iconvs?

Here is two scenarios:

 1. The user installs Subversion on a machine where TortoiseSVN
    already works, and the new iconv are bogus.

 2. The user installs TortoiseSVN on a machine where Subversion
    already works, and the new iconv is bogus.
    The Subversion modules for Apache stops work when they discover
    the new value of the %APR_ICONV_PATH% (for example after a
    reboot) and we have a meltdown.

My guess is that this iconv files will be used by a lot more apps in the
future.

Would it be right to consider one of the solutions:

* All Subversion related apps are using a common %SVN_APR_ICONV_PATH%.
  and installs (reads) the iconv files from one place and every
  package/instructions file makes sure that the files are placed on
  the same common location.

* All users of %APR_ICONV_PATH% are doing the same as above (apache
  related in stead of Subversion related).

* Every app is using their own set of iconv where the app's own
  location for iconv are hardcoded related to the binary that needs
  them.

* You never set the environment variable %APR_ICONV_PATH% if it's
  there already and contains the needed files.

I think that every app should have it's own set of the iconv files and
keep them unshared by opher apps.
The reason is that they are unversioned, we do only have created, last
changed and last accessed times for each file.
The only reliable propery of this is "last accessed time" wich don't tell
us anything about the version of a file.
As an example: The created time for the iso-8859-1.so file on people's
machine will probably be equal with the time they was copyed to the
location they are in, not when they was compiled.

Thoughts?

Jostein

-- 
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 14:05:51 2004

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.