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 <z...@alagazam.net> 24/11/2011 03:54 PM To Humberto Madeira <humberto.made...@trapezegroup.com> cc users <users@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 s...@alagazam.net 23/11/2011 05:05 PM To Humberto Madeira <humberto.made...@trapezegroup.com> cc users@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
