Copy.
-------- Original Message --------
Subject: Re: 1.6.2 Installation Pukes on Windows XP SP3. Problem is
resolved (I hope). Bugs that I have identified. (Correction to earlier
e-mail).
Date: Wed, 20 May 2009 00:28:09 -0400
From: Keith Mitchell <kpmitchell_at_gmail.com>
To: eg <egoots_at_gmail.com>
CC: Bob Archer <bob.archer_at_amsi.com>, users_at_subversion.tigris.org
References: <4A132093.7090409_at_gmail.com>
<CB4587DA62024B40B9F929ECF639210F146644F278_at_USALWEXMB4.infor.com>
<4A1326FB.6020500_at_gmail.com>
Installation Bugs Galore.
My System:
Windows XP Workstation SP3 with
CollabNet Subversion.
TortoiseSVN.
My original CollabNet Subversion Server installation set was created
around 2008-06-26. I not a-priori remove the current installation. The
installer found my installation and asked whether or not I wanted to
overwrite it. I said fine. Wrong Answer. After the fact, I checked
Add/Remove Programs, and CollabNet Subversion Server was not listed
among the installed programs. That is the last place to be updated on a
program change or removal, giving its final status. Looking in the
installed directory there is a scattering of the original installation
and the new one as if the installer just blindly just overwrote things.
This is a clean, simple, and excellent update technique for contained
installations. This is certainly not this installation, close but cigar.
1. I first tried to upgrade my old CollabNet SVN from 1.5.x to 1.6.2.
The installation puked. Thanks to the wonderful responses to my posting
at CollabNet, I found many problems, enough to share with everyone.
Kudos for the tip for debugging .msi files.
2. The CollabNet installation originally puked because certain files in
the 1.5.x distribution had been locked by some mysterious process. The
first file encountered was libsvn_delta-
1.dll. Microsoft SysInternals Process Monitor was not able to identify
the owner of the lock; however, by a process of elimination I tried to
delete the files one-by-one.
3. httpd.exe was locked and stood out as it the only .exe file that
failed. Many .dll's failed. This narrowed things down to the Apache Server.
4. I was running TortoiseSVN too, so I removed TortoiseSVN from my system.
5. As if by magic, all of the file locks that hampered CollabNet
installation magically disappeared!
5.1 Why did Tortoise need the capability to lock CollabNet files much
less have the capability to do so?
5.2 Why didn't CollabNet have a recovery strategy for installation
errors, especially for ones involving difficult to resolve file locks?
6. I restored the CollabNet original file set from my backup that I made
just before I started to manually delete files one-by-one things.
7. I again tried to reinstall CollabNet SVN to 1.6.2. Since all files
are now unlocked, I told the .msi installer to replace the current
version. It puked this time with a 404 error.
8. At this point, I realized the CollabNet Subversion Installation
Procedure itself was screwed up beyond my knowledge and time available.
9. I deleted all of the contents of the normal install directory.
10. I restarted the upgrade process.
11. This time I told the installer to install CollabNet SVN to a new
specially named directory
12. I had Link-Magic create a POSIX symbolic link between the standard
installation and the actual installation location. (Very uncommon in
Gatesware, but is very common in Linux where it is called a sym-link.).
13. I then reinstalled TortoiseSVN.
14. Both upgrades seem to have been successful; however, they have not
been tested. That is for another day.
eg wrote:
> Bob Archer wrote:
>>> I am trying to ugrade SVN from 1.5.X to 1.6.2 in Windows-XP-SP3. When I
>>> run the setup program, it fails with the following ERROR message: It
>>> pukes no matter how the .msi file is launched.
>>>
>>> Can't write: c:\Program Files\CollabNet Subversion Server\libsvn_delta-
>>> 1.dll
>>>
>>> I have closed all window-apps. rtinent, and get the same error message.
>>>
>>> Any ideas what does this error message means and how to correct the
>>> problem?
>>
>> Are you running as an admin? Can you try to install to other than
>> program files? Did you uninstall the previous version first?
>>
>> Do you need the server install?
>
> If you still can't figure it out after answering these questions, the
> typical way to debug MSI installs is by turning on the logging feature
> and wading through the output.
>
> For example, the command below tries to install myinstall.msi and
> outputs verbose logging to c:\myinstall.log:
>
>
> msiexec /i myinstall.msi /l*v c:\myinstall.log
>
>
>
>
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2324468
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-20 07:04:28 CEST