Hello
For our project source code we use standard SVN structure: trunk, branches, tags. Most of development efforts is happening in trunk.
I wonder, what’s the best way to organize project’s Liquibase changeSets in SVN considering above structure?
I want to avoid bulking up change sets for previous releases in the same place, but at the same time I don’t want to delete old files from trunk. So current structure goes to something like
trunk/Liquibase/release-1.9
trunk/Liquibase/release-1.8
etc.
which kills a bit an idea of trunk/ for LQ changeSets but also keeps them saved for later.
Any suggestions how to do it better?
Thanks,
Maciek
You generally want to keep all your old changelog files in your repository. It helps you see how the database evolved, and allows you to bring a blank database up to the current state using the same changesets that have gone through your testing and development throughout the life of your project. Keeping all of them will also allow you to upgrade a dtatabase from, say, 1.6 to 1.9.e
So what I generally do is create a folder within my project with one changelog per release. So something like changelogs/changelog-1.0.xml, changelogs/changelog-1.1.xml, etc. with a main changelogs/db.update.xml that does an to each of the release chagneslogs. As you branch and tag, SVN, all the changelogs will move along with your releases.
Depending on your project, I’ve also seen people do a changelog per feature.
Nathan
