WarnOnOneTimeScriptChanges not behaving as expected

[cabbruzzese]

The option to Warn on OneTimeScriptChanges attempts to rerun the onetime script. This is strange and unexpected behavior. The flag itself indicates that it should produce a warning, NOT any further action. If there were another flag providing this functionality, it would be wonderful. However forcing the script to run again SHOULD always fail by definition. It's a misunderstanding of what the software does to expect it not to fail. The only way for this not to fail are two odd scenarios that require the user to not properly be using RoundhousE

1. Changes to the DB made with another tool that exactly undid all of the changes to the onetime script.
2. A onetime script that is modified to run ANYTIME by checking if the changes have already been made. The script is no longer a one time script after these changes and doesn't even belong in a one time folder.

It's a worst case scenario "feature", because an end user is handed a way to break the software when using it properly. But can only use the feature if entirely misusing the software.

[BiggerNoise]

Yay, it's time to beat the dead horse again.
Read #32 near the bottom for an explanation of the behavior. Your option 2 is the correct remediation.

[cabbruzzese]

If this is a fix, then please change the mission statement that the tool should not limit users, because that's exactly what happened. Especially because the scripts in question are auto generated. Your solution is to go back and re-edit all auto generated create and insert scripts if you want to use a feature?

Again, this is a very strange use case. If a problem arises that requires warn instead of fail, It takes less time to recreate all the scripts than it does to go back through an undetermined amount of history and turn them into anytime scripts. Definitely not a solution. I'm sorry that this whole issue and response has been angry (truly I am) but I've lost quite a bit of time between the 2 issues that I posted and both are seriously legitimate. Another similar issue out there required modifying the hash-string entries every time the project was run because there was no work around due to this behavior. So this really is not a user problem.

If the software is not intended to be used with automatically generated scripts, please mark this in the documentation.

[BiggerNoise]

I am going to respond to this in #175.