Relationships between similar configs¶
I believe there’s an important (unsolved) question here about the relationship between files that have the same regions and/or report settings. If the user decides to change some region or setting, they would have to manually re-do every analysis. how2fix?
Is there a general way to avoid this problem or at least make it less painful?
I can think of some ways, listed below.
User defines “includes”¶
The user has the power to refer to data structures in other files. For example, they would define the shapes and reports for just file A. Then for files B through ZZ they would do the equivalent of “just import * from A”, then maybe add some customization or workarounds specific to file B. If they want to change something in all files, they would modify the common file A.
Pros:
- powerful way for users to get exactly what they want
Cons:
- steep learning curve
- hard to present this to user without confusing them
Stealthy version tracking¶
The user has an “import some settings from other file” option available to them which they can thoughtlessly use to do what they want at the moment (use the same config for a bunch of similar files).
However, the software keeps version and relationship information for all config files. If they later modify file “A”, they can be asked if they also want to update files B-ZZ by performing a (likely fully automatic) 3-way merge between “old-A”, “old-B”, and “new-A”.
Pros:
- maps more to common train of thought “I want to change file A, and also all the other files like A”
- painless common case (merge process hidden from user)
- easier to implement (less custom UI I think), can just call an external graphical merge program
Cons:
- power users may be annoyed by this post-hoc process
- user may be very annoyed if they have to do a manual 3-way merge between yaml files