I get the error below when moving from database version 35 to 40 for
trunk
version 923.
This worked fine when I tested it by just using it as a standalone, but
not
when I tried migrating my existing site.
What’s missing? The site itself is not operating properly while this is
not
migrated.
Processing GeneralController#migrate (for 192.168.5.104 at 2006-03-18
12:12:56) [GET]
Parameters: {“action”=>“migrate”, “controller”=>“admin/general”}
Rendering within layouts/administration
A little clarification. I restarted the server and get “Application
error
(Rails)” with “Multiple migrations have the version number 1” in the
production.log…
And just to answer my own mail one more time… =)
The culprit is in the db/migrations directory. See first the problem site,
then the working site. The problem site has two migrations labeled 1_
The question is, where does that guy belong? Should that be
40_add_extended_html.rb
And why does 0_initial_schema.rb now show up?
It looks to me like a botched svn update gone wrong. 0_initial_schema.rb
and
1_add_extended_html.rb simply shouldn’t be there.
Let me guess, you didn’t update this with svn, but by copying files
from somewhere else. Delete 0_initial_schema.rb and
1_add_extended_html.rb and try the migration again; you should be
okay.
And just to answer my own mail one more time… =)
The culprit is in the db/migrations directory. See first the problem
site,
then the working site. The problem site has two migrations labeled 1_
The question is, where does that guy belong? Should that be
40_add_extended_html.rb
And why does 0_initial_schema.rb now show up?
FIXED!
Since I haven’t set myself up to do a real svn updates, I’ve been doing
a
checkout of the trunk to another area where I do my testing, and then
copy
the new over the old working area. Bad move because one of the
migrations
was… err, migrated to another name. This page that I googled was the
tipoff… http://glu.ttono.us/articles/2005/10/27/the-joy-of-migrations
Deleting 1_initial_schema.rb was the fix. And hopefully someone learns
from
my mistake and sets it up right the first time. In fact, it would be
good
if the Typo instructions only dealt with svn so that its set up right
from
the start to handle updates from trunk or stable or whatever the case
may
be.
the start to handle updates from trunk or stable or whatever the case may
be.
Um… you deleted the wrong one. Not that it matters unless you do
something stupid like trying to migrate all the way back to an empty
database, but you’ll get caught out next time there’s a migration as
well.
I still have the files so if I put the 1_initial_schema.rb back in place
and
remove 0_initial_schema.rb and
1_add_extended_html.rb, will I be in good shape?
Any suggestions for getting myself properly situated with svn in the
current
setup?
I still have the files so if I put the 1_initial_schema.rb back in place and
remove 0_initial_schema.rb and
1_add_extended_html.rb, will I be in good shape?
Should be.
Any suggestions for getting myself properly situated with svn in the current
setup?
Err… run your production code from an svn managed directory?
Ernie I think that Piers is right.
the best way is to have 2 blogs.
a development one to test all the things, your improvements on plugins,
themes, etc… and
a production one with just the “stable updates” both blogs under svn, it
depends just on which update you willl upload.
I’m doing it since several months and it works well.
OK, moved the right files into place. I do have two blogs for this. My
mistake was taking the fresh truck code and working with a copy of the
production database. The site code will have to be copied and then have
the
svn laid on top of that. But better still I’ll have to make sure that
the
Typo areas, production and test, are from svn as Piers suggests.
Thanks!
Any suggestions for getting myself properly situated with svn in
the current
setup?
Err… run your production code from an svn managed directory?
I personally have 3 checkouts on my machine (managed by svk), then
when I want to push to my production blog I use rsync with the
appropriate --delete and --exclude switches so it will delete
unnecessary code files but not delete any cache or public/files stuff.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.