How do you manage your run once sql install scripts in subversion?

Question

I'm working at a company that does several releases to production every year and during the build up to each release we gather up a collection of 1 time sql install scripts like table creation and dataports.

The way things currently work is that after the release to production, we branch, tag then we delete all 1 time scripts from subversion.

This seems to get the job done but to me it never seemed like the proper way to solve the problem.

Could you imagine deleting all your sourcecode every release and then writing patches for production?

The downsides that I see is if you want to reference and old script you have to checkout a tag or branch from subversion.

Our SVN Repo currently looks something like this

svnrepo/mywebsite/src svnrepo/mywebsite/database/storedprocs svnrepo/mywebsite/database/installscripts

I was thinking that a more accurate way to model what we want to do in SVN is the following.

Use an svn:externals attribute to point to the latest version. Then after every release just point it to the latest.

svnrepo/mywebsite/trunk/src/ svnrepo/mywebsite/trunk/src/database/installscripts/ -> svnrepo/mywebsite/trunk/database/Release_3

svnrepo/mywebsite/trunk/database/Release_1 svnrepo/mywebsite/trunk/database/Release_2 svnrepo/mywebsite/trunk/database/Release_3

Using this model we no longer svn delete any sql scripts and enable a database developer to check out svnrepo/mywebsite/trunk/database/ and easily view all the database development that has occurred.

Any comments on my ideas, the current structure, or the best way to manage this situation?

Thanks

Answer 1

Synchronising database changes and code changes in subversion is hard

If you have the option of building the Database from scratch you can put the whole DDL into the repository along with the code, then you don’t need to worry about which changes go with which release.

Looking at your situation I don’t think you need to use externals (they can cause headaches). You also don’t need to delete everything. It is not too difficult to check out a branch (or you could just use a repository browser).

You could even put the old db releases into a separate tag when you release so they are all in one place, which the database people can have checked out. If you are doing releases once a year this won’t be hard.

This question may also help