On Mon, May 18, 2009 at 4:54 PM, jfrapper jfrap...@lycos.com wrote:
How should I hook this into the Liquibase update process. I really dont
want to put it at the end of each differential file. Suggestions?!
I usually put this kind of thing in my Ant script, after the call to
Liquibase update
I guess it is possible to receive emails for every new topic posted to
a board by clicking the Notify button on the board. I would
recommend that for the good old liquibase-user fans like me...
Diego
On Wed, Apr 29, 2009 at 5:15 AM, Voxland, Nathan
nvoxl...@intelligentinsites.com wrote:
I have
I don't care much about this, but I think that anyone who still needs Java 1.4
can download a previous version of Liquibase and use it, right?
Diego
- Mensagem original
De: Paul Keeble cs...@yahoo.co.uk
Para: liquibase-user@lists.sourceforge.net
Enviadas: Segunda-feira, 20 de
Developer A should have merged from the SCM, then done a complete
re-test, including rebuilding the database. At least, that's how I see it.
Yep, that is another solution I'd forgotten, but it is also one I was trying to
avoid. In general, I would not recommend rebuilding the database
Marco, we are currently using an approach that could make your dba happier:
every release, we make an export of the database and use it as a seed for the
next release. This way, we avoid having to re-execute all of the past
changeSets everytime we need a fresh database. I guess this
If you follow the best practices. That means that for every new
changeset... Will you have a new file which wont be comparable against
an old one?
Usually you create a new changeSet for every change to be applied to the
database. Except for rare cases such as when you are starting a brand
David C. Hicks escreveu:
Whether you choose to modify change sets during the Dev-QA cycle really
depends on your internal process, I would say.
On 3/31/09 8:53 PM, Anastasios Angelidis wrote:
How about in Dev-QA cycle, should the changeset be fixed or should a
new
changeset be made to
