# Export MySQL Database Script
mysqldump -uroot -p db_name_1 > dump_name.sql
# Import MySQL Database Script
mysql -uroot -p db_name_2 < dump_name.sql
Importing a MySQL database script (.sql) will potentially overwrite data! (That’s what it’s supposed to do.) Make sure you know that what you’re doing is safe!-)
Done!
Well, here’s an example of mine. Run ‘mate ~/.bashrc’ to view and edit the file, then save it and run ’source ~/.bash_profile’ (on Mac) or whatever your shell equivalent is. Then, you can just use the aliases ‘bashrc’ and ’sourceb’ if you choose to set these aliases as I have.
Okay, so let’s say you host a subversion repository on one server and need to completely move or copy it to a different server or server location. The Tigris guys make it very easy. This information is explained in more detail in the free Subversion PDF titled “Version Control with Subversion 1.4″ starting on page 126. I find it easier here.
It’s time to upgrade your Rails 2.0 application with user authentication, and we hear that RESTful Authentication is the way to go, but all the instructions out there (even on the plugin repository sites) are out of date or don’t completely work or only work on Rails 1.2.x. In this tutorial, however, we’ll go step-by-step to install a complete RESTful authentication suite with all the trimmings your advanced Rails 2.0 application requires. Best of all, we’ll maintain complete source control of our user administration code.
Please note that the code in this tutorial is borrowed from a railsforum.com post by a very smart user named “activefx”. activefx has miraculously put together his research on Rick Olson’s brilliant restful_authentication plugin to create a pretty robust user authentication process. This post is just a bit more tailored for my Rails MVC+ architectural approach, which is to 1) install my plugins (if any), 2) use the Rails generators to generate the resources I think I’ll need, 3) generate my database migrations, add 4) my models (and library modules, if any), then 5) my controllers, and finally 6) my views. This tutorial has also been reorganized and optimized for quick availability to copy and paste into new Ruby on Rails projects.
# on local machine
# check out a working copy of redmine from svn repository trunk
cd ~/work
svn co http://redmine.rubyforge.org/svn/trunk ~/work/redmine_trunk
cd ~/work/redmine_trunk
#
# Configuring and Administering Mongrel Clusters for your Rails Sites
#
Now that we have our Rails site’s vhost setup and enabled in Apache server, and perhaps we’ve enabled our site with Subversion and Capistrano, we can create a Mongrel Cluster configuration to run the wonderful Ruby code we’ve written. We definitely want our Mongrel Cluster to startup when the server reboots, and if we’ve capified our application with Capistrano in Part 5, we’ll want Capistrano to be able to restart our Mongrel Cluster after deploying a new version of our application.
#
# Capistrano setup for Subversion+Capistrano Web Applications
#
Honestly, our days are done with uploading program changes one file at a time, so let’s automate the whole svn commit and application deployment process with an easy-to-use ruby gem called Capistrano. After we “capify” our application, we’ll be able to deploy our application to the remote server with a simple “cap deploy” command. Capistrano will also take care of the svn commit process for the new application release/revision. We’ll still use Subversion for our day-to-day revision commitals, as we do in Part 4, but it’s nice that Capistrano handles a new svn commit upon deployment.
#
# svn setup for Subversion+Capistrano Web Applications
#
If we’re going to be agile developers, we’ll want to employ Subversion and Capistrano to track versions and deploy our applications quickly. Let’s setup a base repository for subversion to call home. Then let’s create an svn repository shell for our project, which we’ll deploy with Capistrano in Part 5. But first, go through these steps for each website’s apache vhost you’ve created in Part 3.
#
# Create Apache Vhosts for Subversion+Capistrano Web Applications
#
Back in Part 2, we installed our Web 2.0 server applications. Let’s continue our Linux web server setup by installing some Web 2.0 sites. Web application sites are handled in apache2 server by setting up vhosts, or virtual hosts. Virtual hosts allow you to setup your websites the way you want, all from a text config file that’s easy to create and make changes to.
Read the rest of this entry »