looking fo the proper handling of config and database schema files in subversion project structure
In SVN we have a project that has all the database logic using hibernate etc. However, that project depends on the database schema being in a certain state that matches the code.
As well, we would also have config scripts that are for the server in runs on in a Config directory.
How does one properly set up the project structure in SVN to overcome this?
The structure could be like this:
--DBHibernateProject ------trunk ------branches ------tags --DatabaseScriptsProject ------trunk ------branches ------tags --ConfigProject ------trunk ------branches ------tags
But how do we tie the database scripts project to say Release-1.0 of the DBHibernateProject? The hibernate project has a deployable asset (jar) in the maven repo, but the db scripts one doesn't. I want to ensure the correct db scripts are tied to the correct release of the application.
If "project depends on ..." means, that "for each and every revision of DBHibernateProject we must to use predefined and fixed revisions of DatabaseScriptsProject and ConfigProject (they used/referenced inside DBHibernateProject tree)" you can always use pure Subversion-side solution: externals with PEG-revisions
Can't say more without knowledge about source-tree structure: "depends on" and "also have config scripts" aren't translatable (easy) into formal dependences, like (my poor reconstruction)
Each revision of DBHibernateProject must have related DatabaseScriptsProject (for correct schema for this code) and ConfigProject (for scripts, which produce database-schema, which is used by DBHibernateProject)
If my reconstruction is correct, in Subversion-style (without Maven, it can be my mistake) I'll create in DBHibernateProject tree two directory-type externals, which referenced to "some tree in some state" in DatabaseScriptsProject and ConfigProject trees respectively
You either do it through process or making one SVN project.
You could, make a rule for the team that when you finish a set of database stuff, you tag it with a tag that is the same as the tag for the code that it works with. This can be tedious but is workable if the changes are typically in-sync between the database and the code.
The other way to do it is to make a single project in SVN with one trunk and one set of tags and branches. Then you accomplish the same thing by having some folders at the top level in the repo that hold code, scripts and hibernate stuff. It is possible to manage permissions on your SVN repo so that different people have write permission on specific folders but that creates a cost to keep modifying the permissions everytime you branch (and maybe tag if you foolishly allow modifying tags)
I would strongly recommend using liquibase to manage your database migrations. The change files are read from the classpath which means they can be deployed in the same jar alongside their matching Hibernate class files.
I've never used it, but liquibase does have some support for hibernate which might prove useful.
For a Maven example see:
For some more theoretical reading I recommend:
In the interest of fairness there are a few other tools in the same functional space:
Couldn't you have a single project layout for the Database project that looks something like this:
----DatabaseProject -------trunk --------DBHibernateProject --------DatabaseScriptsProject -------branches -------tags ----OtherProject -------trunk -------branches -------tags ----ConfigProject -------trunk -------branches -------tags
If the config project is not tied to other projects and just scripts for the server then my guess is you could have it as the same layout as the OtherProject.
- Keep all my SQL scripts in SVN
- Do not allow to modify them (if you want to changes something create new SQL file that contains proper SQL statements)
- Configure maven dbpatch plugin https://github.com/m-szalik/dbpatch-maven-plugin