Doesn't this mean that we won't know which exact version we're running? Just how onerous is it to run a setup version (which needn't be tagged if you're trying to circumvent the system?)

We were thinking that the argument specifying the new pfs_instdata root would in almost all cases be for a different tagged version. In any case the version_pfs_instdata MHS key (and for FITS-writing actors the corresponding card) would change to the git describe --dirty for the new root.

Some actors are problematic to restart. Specifically, the gatevalve gets closed and the H4 DAQ powered off when the controlling actor for each is stopped. That is a property of the kernel driver along with the polarity of the signal lines.

So you'd reload the new code into a running actor?

Configuration not code, but yes. Tell a running actor to use pfs_instdata 1.2 version of its configuration instead of the pfs_instdata 1.1 one it was built against. In practice this is mostly sane, since all current actors load a single config file, which boils down to a single python dictionary. The risk is that other parts of the actor's configuration would change but not get "applied".

One alternative was to support some "patching mechanism", where you basically allow an update of that dict.

We don't love these mechanisms, but are scared worse by not having any. I'd like, at the very least, to have a printout of changes when loading a new version.

Bump. We are and will be testing various ion pump controller configurations on SM3. I made the (very limited) changes to the installed tagged version, but am very unhappy about doing that. Did not want to cycle the gatevalve.

Hmm, thought: we could probably ensure that any new config version is on a git branch based directly off the starting tag. Not sure how, but that feels like something git can let you determine without too much work.