An ECAP feature that would be nice to see in Environments

[Richard Sargent]

ECAP allows you to reset the manager.dat file to a pristine state.

It would be a nice feature to be able to do that from Environments, too.

For example, when I am trying to test a GBS release, if there's an error, I would like to be able to "press reset"and have a clean repository to test the next candidate.

[Bob Brodd]

Hi Richard,

Your post reminded me that we have recently discussed stashing away a copy of the shipped manager in the installation folder (Program Files) so that one always has an easy way to grab it and start fresh. While I understand the usefulness of the 'reset' feature in an ECAP sandbox, it is not as clear how this would function in a multi-installation environment like Environments.  There are several issues that make it more difficult.  

-Since one may have many different installations managed by Environments, which manager would be used on a 'reset' operation?  

-A common scenario in Environments is to connect all development images to a single emsrv controlled manager (containing code for all installed versions of VA Smalltalk) , potentially on a remote machine.  Reseting a remote manager would be challenging, as would knowing what manager to replace it with.

Maybe just having a pristine manager in the installation folder would be useful enough to allow you to write your own 'reset' scripts to do what you need?  Just food for thought ... open to suggestions!

Regards,

Biob

[Richard Sargent]

On Tuesday, November 24, 2020 at 10:04:08 AM UTC-8 Bob Brodd wrote:

Hi Richard,

Your post reminded me that we have recently discussed stashing away a copy of the shipped manager in the installation folder (Program Files) so that one always has an easy way to grab it and start fresh. While I understand the usefulness of the 'reset' feature in an ECAP sandbox, it is not as clear how this would function in a multi-installation environment like Environments.  There are several issues that make it more difficult.  

-Since one may have many different installations managed by Environments, which manager would be used on a 'reset' operation?  

I would suggest that one navigates to the VA Smalltalk Installations "page" and select the one of interest. Doing so would display an additional button to reset the installed manager .dat file. It would help if the details of a given installation showed where the manager .dat file was installed. (I don't see a need to make it edittable, move the file to a new location, or anything else other than have the path be copyable text.)

e.g. The installer puts the file in C:\ProgramData\Instantiations\VA Smalltalk\9.2\manager\mgr921.dat. The Environments tool would allow me to replace that file with the pristine copy. (I suggest the tool work similar to how the image reset tool does, taking a backup of the replaced file, just in case.)

[By the way, the rightmost button's hover help says "Push Button1" rather than something useful like "Installation Root Folders".]

-A common scenario in Environments is to connect all development images to a single emsrv controlled manager (containing code for all installed versions of VA Smalltalk) , potentially on a remote machine.  Reseting a remote manager would be challenging, as would knowing what manager to replace it with.

I think that is beyond what the installer does, so it's out of scope as far as I can see.

Maybe just having a pristine manager in the installation folder would be useful enough to allow you to write your own 'reset' scripts to do what you need?  Just food for thought ... open to suggestions!

Having a pristine copy is minimally sufficient, of course. Remembering the paths is the trickier part. So, having the tool know is preferred.

[Let me close with a reminder of my previous request to include the Environments code in the product installation.]

[Bob Brodd]

Richard,

That sounds reasonable and fits well with my thoughts of  storing a pristine copy of the manager in the Program Files installation folder. I'll open a development case to see about adding this feature to Environments and the installers.

Bob