How to Version Control SQL Scripts Needed for Deployment

A small group of developers and I are working on a side project, and I am currently setting up automated update deployment (for a reasonable definition of automated). Currently, we begin deployment by rebasing our update branch onto our master (production) branch and resolving any residual merge conflicts. Then, our update script gets activated. It completes the merge to master, recompiles the relevant code with production settings, and sends the updated compiled files to the appropriate servers (which will each handle their deployment differently). Finally, the script handles one more important thing: SQL schema updates. With each new version, the developers write a script that performs the necessary schema updates (of course this script gets tested along with all the other code that is written). On the one hand, there are many reasons that such a script does belong in version control: Many developers are working on this and changing it overtime, seeing who made what changes is useful, the ability to roll back changes is useful, etc. However, there is a distinct difference between this script and most source code: It does not persist for more than the duration of a single update. In particular, once the update for that script is released, we have no more use for that script, and version controlling it no longer makes sense. What is the right thing to do at this point? Should the deployment script add a new commit that wipes the SQL schema change script? Should we attempt to write the script in such a way that it does not need to be wiped? (with a large number of CREATE IF NOT EXISTs)