2019-12-15 08:42 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000977Spring engineGeneralpublic2008-07-13 04:46
Reporterbibim_ 
Assigned ToKloot 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionno change required 
Product Version0.76b1+svn 
Target VersionFixed in Version 
Summary0000977: [SVN6151] Multiple Spring installations on windows
DescriptionOn 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 :/
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0002407

Kloot (developer)

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.)

~0002408

bibim_ (reporter)

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.

~0002414

LordMatt (reporter)

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.

~0002416

bibim_ (reporter)

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 ;)

~0002417

LordMatt (reporter)

Closed as requested.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History