|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000977||Spring engine||General||public||2008-07-12 11:15||2008-07-13 04:46|
|Status||resolved||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0000977: [SVN6151] Multiple Spring installations on windows|
|Description||On first Spring installation on Windows, the HKEY_CURRENT_USER/Software/SJ/spring/SpringData key is created in registry, and its value is initilized to the chosen installation directory. Then, when a new Spring installation is started, it uses this key to propose a default installation directory. But if we choose a different location to keep 2 different Spring revisions installed, then the registry key isn't updated. Then when we start the newly installed Spring revision, unitsync uses the old installation directory as "read-write data directory" (it creates the ArchiveCache files inside the old installation directory for instance), which leads to unitsync inconsistencies followed by TASClient crash on my system. Updating the registry key on each installation wouldn't solve the problem because then the old installations wouldn't work anymore :/|
|Tags||No tags attached.|
|Checked infolog.txt for Errors|
Last edited: 2008-07-12 14:24
Spring's version string is now appended to its registry node (so "HKEY_CURRENT_USER/Software/SJ/spring" becomes eg. "HKEY_CURRENT_USER/Software/SJ/Spring 0.76b1+"), so you can have a release and an SVN build installed concurrently.
(Note that you could also do this by using the /config commandline option which overrides the default.)
Thanks Kloot for taking a look at this.
Actually my problem was between 2 SVN installations (0.76b1 doesn't seem to use the registry key so it can't be impacted), so I guess this won't fix it :/
Anyway, it's clearly not a big problem for dev ppl who can fix this by themselves with "/config" parameter as you said, but I think common players are gonna be lost if Spring stops working just because they reinstalled it somewhere else (whereas it used to work with Spring 0.76b1). It's quite common for non-dev players to have multiple spring installation. Lots of players try to fix problems just by reinstalling Spring somewhere else, or they reinstall Spring in order to have a dedicated springie instance for example). But with current implementation, this would give them even more obscur problems.
|I don't have any such key in my registry, before or after installing with the latest revision installer, nor can I see where it is set in the installer source.|
Actually I think my SpringData key had been initialized during the first Spring run, not during the installation itself.
Anyway, I just removed my SpringData key from registry, and restarted a recent SVN Spring revision. Indeed you're right, it hasn't been initialized when I relaunched Spring (it has been created but with empty value, which is consistent with current DataDirLocater SVN code and doesn't produce the bug). So I guess this bug was due to an old SVN release which had initialized the SpringData key in my registery, quite tricky...
issue can be re-closed, sorry for this false alarm ;)
|Closed as requested.|
|2008-07-12 11:15||bibim_||New Issue|
|2008-07-12 14:20||Kloot||Note Added: 0002407|
|2008-07-12 14:24||Kloot||Note Edited: 0002407|
|2008-07-12 14:43||Kloot||Status||new => resolved|
|2008-07-12 14:43||Kloot||Resolution||open => fixed|
|2008-07-12 14:43||Kloot||Assigned To||=> Kloot|
|2008-07-12 15:14||bibim_||Status||resolved => feedback|
|2008-07-12 15:14||bibim_||Resolution||fixed => reopened|
|2008-07-12 15:14||bibim_||Note Added: 0002408|
|2008-07-12 23:28||LordMatt||Note Added: 0002414|
|2008-07-13 02:33||bibim_||Note Added: 0002416|
|2008-07-13 04:45||LordMatt||Note Added: 0002417|
|2008-07-13 04:46||LordMatt||Status||feedback => resolved|
|2008-07-13 04:46||LordMatt||Resolution||reopened => no change required|