Aah, I see where I went wrong. I am using SQLite3, that DB is stored in db/production.sqlite3 and that file is not under version control. Get it now!
On Jul 25, 10:32 pm, "Jamis Buck" <[EMAIL PROTECTED]> wrote: > deploy:migrate is a potentially very time-consuming process that (on > large databases) can basically make your application unavailable for > long periods of time. Thus, if you want it, you need to ask for it by > name. If you always want your deploy to also run migrate, you can use > deploy:migrations instead of simply deploy. Or, you can do as others > before you have done, and add: > > after "deploy:update_code", "deploy:migrate" > > - Jamis > > On 7/25/07, harm <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > I succesfully ran a 'cap deploy:cold' and got back tinkering on my > > app. However when I commited my changes to the repository I wanted to > > redeploy. So I ran 'cap deploy', this seemed to work however it did > > wreck my production DB(problem 1) and I had to run 'cap > > deploy:migrate' before I even got a working app again(problem 2). > > Now I get problem 1, it is an other iteration so throwing away the DB > > is a good idea. What I dont get is problem 2. Why is this not ran? It > > should, IMHO. Can someone explain to me the logic behind this? > > > Thanks! > > > Harm --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
