Hi David,
>For the users the path is HKEY_USERS\<userid>\Environement
Yes, or simply HKEY_CURRENT_USER\Environment
However, this install was meant to be used as a server for multiple users.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment
just contains all of the data from the System/Environment panel.
>I noted that APR_ICONV_PATH is set as User environment variable, maybe
you did previous installs for another user and that users variable had the
value from this install ?
Oops, sorry. Good point - I always manually change this value to a system
environment variable (this is a server after all)
>I don't know why it's set just for current user. I didn't create the
install scripts, just using them and making necessary modifications. Maybe
I should change this for upcoming releases.
I always assumed it was optimized for someone who used Subversion locally
on their desktop, with command line mode for the primitive "au naturel"
types.
The manual and various example pages talk about this option "a lot" which
was probably good in the early evangelism phase.
>It could also be that you used the very old exe-installer from Tigris.
Possible, I've been using it at work awhile - since version 1.2 or
something like that. (longer at home)
But in this instance, I seem to remember modifying it manually (a few
years back)
Either way, I always verify that it is set "correctly" as a system
variable, no matter how it is installed.
In any case, I'm not so sure the APR_ICONV_PATH had that much effect on
the overall installation.
The Python trace only went away when I finally changed the path settings -
it looks like Python needs to find the Subversion\bin DLL's no matter
what.
Hmmm, I can see that detection of these sorts of modified settings can be
pretty difficult without some sort of uninstaller info.
Maybe that's why so many MSI installers stuff data into the registry
The Apache httpd windows installer has a setting for "local use" versus
"used by everybody".
And they also allow you to install into a non-default folder
Looking into the registry, I see the following entry
HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Apache\2.2.21
(Default) ReG_SZ (value not set)
ServerRoot REG_SZ c:\Apache\Apache2.2
Shared REG_DWORD 0x00000001 (1)
Perhaps a similar one at
HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Subversion\1.7.2
might be in order? At least for any decisions taken during the install.
Another thing to consider, is to set up something like a SVN_HOME
environment variable, or possibly SUBVERSION_HOME
and then you can set %SVN_HOME%\bin into the path and %SVN_HOME%\iconv
into APR_ICONV_PATH
That way, anyone changing the location of the Subversion install only has
to change it in one place,
or you can even create a batch file to re-register the new location via
the magic of %~dp0
Best Regards,
--Bert
David Darj <zid_at_alagazam.net>
24/11/2011 03:54 PM
To
Humberto Madeira <Humberto.Madeira_at_trapezegroup.com>
cc
users <users_at_subversion.apache.org>
Subject
Re: Bug: Subversion Windows installer not setting paths correctly
Hi again Bert.
Today I've tested this on a (almost) clean Win7 installation I had without
problems.
I did first a clean install to C:\Test\Subversion... APR_ICONV_PATH was
set correctly.
I also did a install of first 1.6.17 to C:\Program Files\Subversion and
then an "upgrade" to 1.7.1 to C:\Test\Subversion and the only traces of
the 1.6.17 install was some licence files and in the PATH environment
variable. APR_ICONV_PATH was correct this time too.
I noted that APR_ICONV_PATH is set as User environment variable, maybe you
did previous installs for another user and that users variable had the
value from this install ?
I don't know why it's set just for current user. I didn't create the
install scripts, just using them and making necessary modifications. Maybe
I should change this for upcoming releases.
It could also be that you used the very old exe-installer from Tigris.
This one (from what I found in the source code in the repository) did set
APR_ICONV_PATH for both current user and for system.
You can check the environment variables in the registry by running regedit
as administrator.
For the users the path is HKEY_USERS\<userid>\Environement
and for all users
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Environment
/David
ps. Please use "Reply to all" so subsequent mail is also sent to the list
for others to follow and search for solutions.
On 2011-11-23 23:36, Humberto Madeira wrote:
Hi David,
I actually had 2 installs, one was 1.7.0 and the other was 1.7.1
Both previously had Subversion 1.6.x and Python 2.5.x on them, installed
on the default path.
I had recently decided that since I put all my Apache products under
c:\Apache
now that Subversion also qualifies as Apache, I should move it under the
Apache tree, so to speak.
I made both changes on the 1.7.0 box a couple of weeks ago, (updating from
1.6.x) ran into this problem,
didn't write it down (too busy) and left that one working.
Then I made the change on the new 1.7.1 this week and ran into the same
problems (thinking I had set the path properly)
So I ran into the same wild goose chase again until I decided to compare
the fully working one to the partly working one.
On older versions I just accepted the default path.
Regards,
--Bert
svn_at_alagazam.net
23/11/2011 05:05 PM
To
Humberto Madeira <Humberto.Madeira_at_trapezegroup.com>
cc
users_at_subversion.apache.org
Subject
Re: Bug: Subversion Windows installer not setting paths correctly
On 2011-11-23 21:44, Humberto Madeira wrote:
Hi all,
I ran across a bug with the Windows (msi) Subversion installer where it
was not setting the paths correctly during an install with a non-default
path.
To Reproduce:
1) download Setup-Subversion-1.7.1.msi from
http://sourceforge.net/projects/win32svn/files/1.7.1/Setup-Subversion-1.7.1.msi/download
2) use it to install Subversion into c:\Apache\Subversion instead of the
default c:\Program Files\Subversion
You will find the files in the correct place, but the APR_ICONV_PATH and
the PATH will still point to c:\Program Files\Subversion
>Your operating system
Windows Server 2003 Standard Edition (32 bit) Service Pack 2
>The release and/or revision of Subversion
1.7.1
>The compiler and configuration options you built Subversion with
binary built and packaged by David Darj and up on SourceForge (see
above)
>Any private modifications you made to your Subversion
nope
>The version of Berkeley DB you're running Subversion with, if any
nope - using FSFS
>Anything else that could possibly be relevant. Err on the side of too
much information, rather than too little.
Using it with Apache httpd-2.2.21-win32-x86-openssl-0.9.8r.msi (not
using the SSL)
Using it with Python2.7.2 from Python.org
Using the python bindings svn-win32-1.7.1_py27.zip from David Darj
(as per above)
Note: this path problem is not easy to spot (if you didn't expect it) so I
first caught it when trying to commit.
Since I use case-insensitive.py in the pre-commit hook - the problem gets
reported in the Python stack trace
- which then leads you onto a wild goose chase in the Python path setup
(which is actually fine but since you aren't able to tell, distracts you
from the real problem)
Best Regards all
--Bert
Hi Bert.
Thanks for the bug report.
I'll try to look into this problem in the next few days. My first look at
the installer build file it seems to be set correctly as
"[INSTALLDIR]iconv" and a quick test on my old Win2000Server did set the
correct path (but the notes on the installer end page was wrong).
Is this a fresh install of Subversion or did you upgrade from a previous
version, maybe installed on the default path?
Have you experiences this problem on previous versions of my installers ?
Regards
/David
Received on 2011-11-24 23:11:47 CET