Re: Bug: Subversion Windows installer not setting paths correctly

2011-11-24 Thread David Darj

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




Re: Bug: Subversion Windows installer not setting paths correctly

2011-11-24 Thread Humberto Madeira
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)
ServerRootREG_SZc:\Apache\Apache2.2
SharedREG_DWORD0x0001 (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

Re: Bug: Subversion Windows installer not setting paths correctly

2011-11-23 Thread svn

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