--warnandignoreononetimescriptchanges

[erikbra]

Warn on one time script changes, bug ignore them, do not run the changed script.

Do we want/need this?

[wokket]

I read this as effectively providing --baseline but for the OneTime scripts only.... I can see why you might need this if restoring a db from another environment, which had tokens in a one-time script and so the db hash will never match your current files, but because you're in a downlevel environment (restored db) you have changes to run and can't use --baseline.

I may have used this in the distant past whern I was using restores more, but the distant past is hazy...

[erikbra]

I have never used this one.

BTW (maybe unrelated), what's your take on this? Should we store the scripts before replacing tokens, or after?

chucknorris/roundhouse#419

[wokket]

I completely understand why storing scripts before tokens are replaced makes sense, esp in that "restore downlevel" scenario. If I was starting a dbase migration project from scratch with no concern for back compat that's prob what I'd try.

A couple of thoughts against though:

• Back compat with existing hashes/text/dbases... could be managed with (not yet avail) --baseline or this issues --warnandignoreononetimescriptchanges ?
• Would you apply the hash checks before or after replacement? You'd really want to check the before if you're storing the before in the dbase, and for the restore scenario (or build(deps): bump xunit from 2.6.3 to 2.6.5 #419) to make sense. You really want to check after replacement to detect changes in token values in the same environment where it's already run...
• Per-token values like suggested in Tokenized scripts to be persisted as is chucknorris/roundhouse#419 feels like a hiding to nowhere right now while we're still ticking off basic stuff but it's a legit feature request...