From cb3339838e1874346167fc6f20b2b2e4f6ea9604 Mon Sep 17 00:00:00 2001 From: Dan Rice Date: Sun, 3 Feb 2013 11:33:49 -0500 Subject: [PATCH] Move install and upgrade instructions into the main Tracks release --- doc/installation.textile | 153 +++++++++++++++++++++++++ doc/upgrading.textile | 238 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 391 insertions(+) create mode 100644 doc/installation.textile create mode 100644 doc/upgrading.textile diff --git a/doc/installation.textile b/doc/installation.textile new file mode 100644 index 00000000..2bdc066c --- /dev/null +++ b/doc/installation.textile @@ -0,0 +1,153 @@ +--- +title: "Manual - Installation" +layout: page +comments: false +sharing: false +footer: false +--- + +"« Introduction":/manual/ - "Upgrading »":/manual/upgrading.html + +h2. Installing Tracks + + +h3. Getting Tracks + + +There are two methods of downloading Tracks: + +# (Recommended for most people) Download the "zipped package":{{ site.download_link }} for the latest stable release ({{ site.version }}) and unzip in your preferred location (e.g. @~/Sites@ for Mac OS X users). +# If you want to live on the edge, you can get the latest development version from GitHub using git (bear in mind that this may be less stable than the released versions): + +{% codeblock lang:bash %} +cd ~/Sites +git clone git://github.com/tracksapp/tracks.git +cd tracks +{% endcodeblock %} + + +h4. Easy installation options + + +There are a few easy options if you are not confident about installing Tracks from source using these instructions. If you'd like to install Tracks on a local machine, try "BitNami":http://bitnami.org/stack/tracks -- it runs on Windows, Mac OS X and Linux. But they also support preconfigured virtual machines, including Amazon machine images. + +Alternatively, you could try "JumpBox":http://jumpbox.com/app/tracks, who provide a JumpBox for Tracks. JumpBoxes are pre-built, pre-configured virtual applications which run in a range of "Virtualization software applications":http://www.jumpbox.com/supported-virtualization-software. You just download the JumpBox (free), then open the file with your Virtualization software. Once the JumpBox has booted, it will give you a URL which you can visit in a browser. The software will then guide you through setting up an account. If you'd like to try out the JumpBox without installing it, you can use the 'Trial This JumpBox' button on the web site, which will let you play around with it to test it out. Furthermore, there is a free public AMI available for Amazon EC2. Just use any EC2 client and search for Tracks. This works in exactly the same way as the downloaded JumpBox you can easily migrate from a downloaded installation to an EC2 instance or back using the backup system of the JumpBox. + +Several third parties provide Tracks hosting as a service. A list of these providers can be found "on the wiki":https://github.com/TracksApp/tracks/wiki/Tracks-hosting. Please note that they may run older versions of Tracks. + + +h4. Requirements + + +The Tracks interface is accessed through a web browser, so you need to run a webserver to serve the Tracks pages up to you. This isn't as daunting as it sounds, however: Tracks ships with a built-in web server called Mongrel which you can run on your own computer to serve the Tracks application locally. If you want to be able to access Tracks from any computer connected to the Internet, then you need to install Tracks on a publicly accessible server, and you will probably be better off using a more robust web server such as "Apache":http://www.apache.org/ (using "modrails":http://www.modrails.com/) or "Lighttpd":http://www.lighttpd.net/ to serve the pages, particularly if it will be used by many people. + +Tracks stores its data in a database, and you can either use SQLite3, MySQL or PostgreSQL. SQLite3 is the best choice for a single user (or a small number of users) on a local installation, while MySQL or PostgreSQL is better for multiple users on a remote installation. + + +h4. What is included with the Tracks package? + +# Tracks itself +# An empty SQLite3 database, set up with the correct database schema + + +h4. What you need to install + +If you don't want to (or can't) use one of the all in one installations, you'll need to install a few things, depending on your platform and your needs. + +# *Ruby*. Tracks requires either Ruby 1.8.7 or Ruby 1.9.x. Ruby 1.9.x is the recommended version. +# *RubyGems*. Tracks was tested on version 1.8.24. You may upgrade using @gem update --system@. The gems needed by Rails to interact with the database have to be compiled on the platform on which they will be run, so we cannot include them with the Tracks package, unlike some other gems. So you will need to "download":http://rubyforge.org/frs/?group_id=126 and install RubyGems (run @ruby setup.rb@ after extracting the package). If you use Linux, rubygems may be available throught your packaging system. Mac OS X users already have RubyGems and the SQLite3 gem already installed on their systems. Once installed you can use RubyGems to install the gems you need for your database. Run @bundle install --without development test@ from the directory you installed Tracks in. This will install all needed gems, including those for MySQL and Sqlite3. If you do not want one of them, you can comment it out in your @Gemfile@ which can be found in the root of the Tracks installation. +# *Database*. The easiest option is to use SQLite3, as the database is included in the package. You may need to install it first for your platform (see "sqlite.org":http://sqlite.org/download.html for downloads and installation instructions). If you want to use MySQL, download and install a package for your platform from "MySQL.com":http://dev.mysql.com/downloads/mysql/5.0.html. The basic steps for Postgresql should be similar to those for MySQL, but they will not be discussed further here. + + +Various Tracks users have contributed installation howtos for specific setups. They are "on the wiki":https://github.com/TracksApp/tracks/wiki/Installation-index. + + +h3. Installation + +This description is intended for people installing Tracks from scratch. If you would like to upgrade an existing installation, please see Upgrading to Tracks {{ site.version }}. + +# Unzip tracks and install in a directory +# Decide on a database to use +## SQLite3 - change database.yml to point to SQLite3 database. Make sure you add the complete path to the database. Remove the @mysql2@ gem from the Gemfile +## MySQL - create new MySQL db and grant all privileges +# Install the necessary prerequisites using Bundler +# Configure some variables +# Populate the database with the Tracks schema +# Start the server +# Visit Tracks in a browser +# Customise Tracks + + +h4. Unzip Tracks and install + +Unzip the package and move Tracks into the directory you want to run it from. For example, for Mac OS X users, @~/Sites@ is a good choice. + + +h4. Decide on a database + +Before you go any further, you need to decide which database you will use. See the 'What you need to install' section for details on installing the required components for you choice of database. + +# *SQLite3*. All you need to do is make sure that you point Tracks to the included SQLite3 database in @/db@ in the next step, 'Configure variables'. +# *MySQL*. Once you have MySQL installed, you need to create a database and database-user to use with Tracks. For this, you can use MySQL Administrator or go into a terminal and issue the following commands: + +{% codeblock lang:mysql %} +mysql -uroot -p +mysql> CREATE DATABASE tracks; +mysql> GRANT ALL PRIVILEGES ON tracks.* TO yourmysqluser@localhost \ +IDENTIFIED BY 'password-goes-here' WITH GRANT OPTION; +{% endcodeblock %} + +h4. Install the necessary prerequisites using Bundler + +Tracks makes use of several other Ruby libraries (known as 'gems') to provide additional functionality. The Bundler tool makes it easy for the gems that Tracks needs to be installed. + +# Make sure you have bundler on your system already. It can be installed by running @gem install bundler@ +# Run the command @bundle install --without development,test@ in the directory that you unzipped your Tracks download to. +# Wait for Bundler to finish installing the necessary gems that Tracks needs. This can take some time depending on the speed of your internet connection and the speed of the system you're installing Tracks on. + +h4. Configure variables + +# If you downloaded Tracks via GitHub, you need to duplicate the files @database.yml.tmpl@ and @site.yml.tmpl@ and remove the @*.tmpl@ extension from the duplicates. Once you've made those copies, edit the files as described in steps 2 and 3. +# Open the file @/config/database.yml@ and edit the @production:@ section with the details of your database. If you are using MySQL the @adapter:@ line should read @adapter: mysql2@, @host: localhost@ (in the majority of cases), and your username and password should match those you assigned when you created the database. If you are using SQLite3, you should have only two lines under the production section: @adapter: sqlite3@ and @database: db/tracks-blank.db@. +# Open the file @/config/site.yml@, and read through the settings to make sure that they suit your setup. In most cases, all you need to change are the @salt: "change-me"@ line (change the string "change-me" to some other string of your choice), the administrator email address (@admin_email@), and the time zone setting. For the time zone setting you can use the command @bundle exec rake time:zones:local@ to see all available timezones on your machine +# If you are using Windows, you may need to check the 'shebang' lines (@#!/usr/bin/env ruby@) of the @/public/dispatch.*@ files and all the files in the @/script@ directory. They are set to @#!/usr/bin/env ruby@ by default. This should work for all Unix based setups (Linux or Mac OS X), but Windows users will probably have to change it to something like @#c:/ruby/bin/ruby@ to point to the Ruby binary on your system. +# If you intend to deploy Tracks with the built in webserver called WEBrick, you'll need to change @config.serve_static_assets@ to @true@ in @config/environments/production.rb@ in order for the images, stylesheets, and javascript files to be served correctly. + + +h4. Populate your database with the Tracks schema + +Open a terminal and change into the root of your Tracks directory. Enter the following command: + +{% codeblock lang:ruby %} +bundle exec rake db:migrate RAILS_ENV=production +{% endcodeblock %} + +This will update your database with the required schema for Tracks. If you are using SQLite3, it is not strictly necessary, because the SQLite3 database included with Tracks already has the schema included in it, but it should not do any harm to run the command (nothing will happen if it is up to date). + +h4. Precompile assets + +Static assets (images, stylesheets, and javascript) need to be compiled in order for them to work correctly with the new asset pipeline feature in Rails. Precompiling your assets is as simple as running the following command while inside the Tracks root directory: + +{% codeblock lang:ruby %} +bundle exec rake assets:precompile +{% endcodeblock %} + +h4. Start the server + +While still in the Terminal inside the Tracks root directory, issue the following command: + +{% codeblock lang:ruby %} +bundle exec rails server -e production +{% endcodeblock %} + +If all goes well, you should see some text informing you that the WEBrick server is running: @=> Rails application starting in production on http://0.0.0.0:3000@. If you are already running other services on port 3000, you need to select a different port when running the server, using the @-p@ option. You can stop the server again by the key combination Ctrl-C. + + +h4. Visit Tracks in a browser + +Visit @http://0.0.0.0:3000/signup@ in a browser (or whatever URL and port was reported when you started the server in the step above) and chose a user name and password for admin user. Once logged in as admin, you can add other (ordinary level) users. If you need to access Tracks from a mobile/cellular phone browser, visit @http://yourdomain.com/mobile/@. This mobile version is a special, lightweight version of Tracks, designed to use on a mobile browser. + + +h4. Customise Tracks + +Once logged in, add some Contexts and Projects, and then go ahead and add your actions. You might also want to visit the Preferences page to edit various settings to your liking. Have fun! diff --git a/doc/upgrading.textile b/doc/upgrading.textile new file mode 100644 index 00000000..8890fca7 --- /dev/null +++ b/doc/upgrading.textile @@ -0,0 +1,238 @@ +--- +title: "Manual - Upgrading" +layout: page +comments: false +sharing: false +footer: false +--- + +"« Installation":/manual/installation.html + +h2. Upgrading Tracks + +h3. Upgrading from Tracks 2.1.x/2.2RC to 2.2 + +This release adds a variety of new features and bugfixes to Tracks. + +The database will need to be migrated as part of the install. + +To upgrade: +# Back up your existing database and installation of Tracks +# Install Tracks 2.2 in a new directory +# Copy over the configuration from your previous Tracks installation. If using SQLite3, copy the old database into the new Tracks 2.2 directory. +# Check that you have all dependencies installed: @bundle install --without development test@ +# Run @bundle exec rake db:migrate RAILS_ENV=production@ to update your old database to the new schema. This is the point of no return. Make sure you have backups! +# The administrator email address shown on the signup page is now configured in @config/site.yml@. Edit your @config/site.yml@ and add an @admin_email@ option. See @config/site.yml.tmpl@ for an example. +# If you're using mysql, change the database adapter from @mysql@ to @mysql2@ in your @config/database.yml@ file. The @mysql2@ adapter replaces the @mysql@ adapter in Rails 3.2 +# Precompile your static assets (css, javascript, etc.) by running @bundle exec rake assets:precompile@ +# Run @bundle exec rails server -e production@ inside your Tracks 2.2 directory to start up Tracks 2.2. +# Once you are happy that everything is working well, delete your old Tracks directory. + +h3. Upgrading from Tracks 2.1.1 to 2.1.2 + +The purpose of this release is to address several security vulnerabilities that were recently discovered in Rails. For details about the contents of the release, please see the "difference view":https://github.com/TracksApp/tracks/compare/v2.1.1...v2.1.2 on GitHub. + +There are no changes done to the database, it is therefore not necessary to run the migrations. To upgrade: + +# Back up your existing database and installation of Tracks +# Install Tracks 2.1.2 in a new directory +# Copy over the configuration from your previous Tracks installation. If using SQLite3, copy the old database into the new Tracks 2.1.2 directory. +# Check that you have all dependencies installed and up-to-date: @bundle install --without development test@ +# Run @bundle exec script/server@ inside your Tracks 2.1.2 directory to start up Tracks 2.1.2. +# Once you are happy that everything is working well, delete your old Tracks directory. + + +h3. Upgrading from Tracks 2.1 to 2.1.1 + +This release is a bugfix release. For details about the fixes, see the "difference view":https://github.com/TracksApp/tracks/compare/v2.1...v2.1.1 on Github. + +There are no changes done to the database, it is therefore not necessary to run the migrations. For upgrading: + +# Back up your existing database and installation of Tracks +# Install Tracks 2.1.1 in a new directory +# Copy over the configuration from your previous Tracks installation. If using SQLite3, copy the old database into the new Tracks 2.1 directory. +# Check that you have all dependencies installed and up-to-date: @bundle install --without development test@ +# Run @bundle exec script/server@ inside your Tracks 2.1.1 directory to start up Tracks 2.1.1. +# Once you are happy that everything is working well, delete your old Tracks directory. + +h3. Upgrading from Tracks 2.0 or 2.1RC1 to 2.1 + +For the upgrade, please note that with version 2.1 Tracks started to use @bundler@. This means you need to have to install bundler using @gem install bundler@. + +To upgrade: +# Back up your existing database and installation of Tracks +# Install Tracks 2.1 in a new directory +# Copy over the configuration from your previous Tracks installation. If using SQLite3, copy the old database into the new Tracks 2.1 directory. +# Check that you have all dependencies installed: @bundle install --without development test@ +# Run @bundle exec rake db:migrate RAILS_ENV=production@ to update your old database to the new schema -- you did back up your database didn't you? +## This may take a while! +# Run @bundle exec script/server@ inside your Tracks 2.1 directory to start up Tracks 2.1. +# Once you are happy that everything is working well, delete your old Tracks directory. + +If you did not start with a new copy of Tracks as described above, but installed over an older version (or used git to pull in a newer version), you may need to remove the cached version of the javascript and stylesheets of Tracks. +# jquery-cached.js from public/javascripts +# tracks-cached.js from public/javascripts +# tracks-cached.css from public/stylesheets + +If you are running an older version of Tracks (1.8devel), they could also be called jquery-all.js, tracks.js and all.css + +If you have problems with Passenger not finding the gems bundler installed, you might want to let bundler put all gems in the Tracks directory so that Passenger can find them (and probably have sufficient permissions). Create a directory @.bundle@ in your Tracks root directory. Add the following config in @/path/to/tracks/.bundle/config@: + +{% codeblock lang:ruby %} +--- +BUNDLE_DISABLE_SHARED_GEMS: "1" +BUNDLE_PATH: /path/to/tracks/.bundle +{% endcodeblock %} + +h3. Upgrading from Tracks 2.0RC2 to 2.0 + +The upgrade to the latest stable 2.0 release consists of the same steps as upgrading from 1.7.x in the following paragraph, just replace 2.0RC with 2.0 where appropriate + +PLEASE NOTE that the requirements for Tracks have changes: +# Rubygems needs at least version 1.3.7 or above. 1.3.7 and 1.5.0 are tested. 1.7.0 does not work for this release of Tracks +# Only Ruby 1.8.7 is supported, both 1.8.6 and 1.9.x are not tested and are known to have issues. + +h3. Upgrading from Tracks 1.7.x or from 2.0RC1 to Tracks 2.0 final + +NOTE +# these instructions will work too if you are upgrading to latest 2.0devel tree. +# Actually no 2.0RC1 release was done, but some people have been using a development version referred to as RC1. Upgrading is the same as from 1.7.x to RC2. + +To upgrade: +# Back up your existing database and installation of Tracks +# Install Tracks 2.0RC in a new directory +# Copy over the configuration from your previous Tracks installation. If using SQLite3, copy the old database into the new Tracks 2.0RC directory. +# Run @rake db:migrate RAILS_ENV=production@ to update your old database to the new schema -- you did back up your database didn't you? +# Run @script/server@ inside your Tracks 2.0RC directory to start up Tracks 2.0RC2. +# Once you are happy that everything is working well, delete your old Tracks directory. + +If you did not start with a new copy of Tracks as described above, but installed over an older version (or used git to pull in a newer version), you need to remove the cached version of the javascript and stylesheets of Tracks. +# jquery-cached.js from public/javascripts +# tracks-cached.js from public/javascripts +# trachs-cached.css from public/stylesheets + +If you are running an older version of Tracks (1.8devel), they could also be called jquery-all.js, tracks.js and all.css + +h3. Upgrading from Tracks 1.7 or 1.7.1 or 1.7.2 to 1.7.3 + +The 1.7.1, 1.7.2 and 1.7.3 releases are bug fix releases that do not contain changes to the database structure. You can unzip the new release over your current 1.7 or 1.7.1 install. +It is also possible to follow the instructions below and copy your existing site.yml and database.yml from your Tracks 1.7 install. + +h3. Upgrading from Tracks 1.7RC2 to Tracks 1.7 + +There were only a few fixes in the code, so you can consider unzipping the new release over your install of Tracks 1.7RC2. Do make a backup of your Tracks 1.7RC2 install and your database! + +It is also possible to follow the instructions below and copy your existing Site.yml from your Tracks 1.7RC2 install. + +h3. Upgrading from Tracks 1.5, 1.6 or from Tracks 1.7RC1 to Tracks 1.7 + +In Tracks 1.7 (since RC2) the site specific configuration is moved from @environment.rb@ into the new @site.yml@. This makes updating @environment.rb@ much easier without you needing to set your site specific settings after each update. + +After you install Tracks 1.7 there will be no @environment.rb.tmpl@ anymore. You will find an @environment.rb@ which you can leave untouched. Just fill in your settings from your old @environment.rb@ in the new @site.yml@. If you have made any other customisations to @environment.rb@ in the past, you can put them in your own configuration file (for example, in my-config.rb) in @config/initializers@. Please let us know it you think they should be in @site.yml.tmpl@ + +Also, there were some database changes made in Tracks 1.7, so you need to migrate to them. + +# Back up your existing database and installation of Tracks +# Install Tracks 1.7 in a new directory +# Copy over the configuration from your previous Tracks installation (except for environment.rb, see above). If using SQLite3, copy the old database into the new Tracks 1.7 directory. +# Run @rake db:migrate RAILS_ENV=production@ to update your old database to the new schema -- you did back up your database didn't you? +# Run @script/server@ inside your Tracks 1.7 directory to start up Tracks 1.7. +# Once you are happy that everything is working well, delete your old Tracks directory. + +h3. Upgrading from Tracks 1.043 to 1.7 + +This should be a relatively straightforward, and involves the following main steps: + +# Back up your existing database and installation of Tracks +# Install Tracks 1.6 in a new directory +# Copy over the configuration from your previous Tracks 1.043 installation. If using SQLite3, copy the old database into the new Tracks 1.7 directory. +# Run @rake db:migrate RAILS_ENV=production@ to update your old database to the new schema -- you did back up your database didn't you? +# Run @script/server@ inside your Tracks 1.7 directory to start up Tracks 1.7. +# Once you are happy that everything is working well, delete your old Tracks directory. + +h3. Detailed steps + +h4. Backing up + +It's very important that you *back up your database* before you start the upgrade process. It's always possible for things to go wrong with the database update, and you don't want to lose any data. If you are using SQLite3 and you are leaving your old Tracks directory in place, then you don't need to do anything. However, there is no harm in taking extra precautions and copying your database from @/db@ to a safe location as an extra backup, or making a dump of the schema and contents. You will never regret making too many backups! If you are using MySQL, make a SQL dump of your database, replacing the terms in square brackets with the correct information for your setup: + +
+  
+    mysqldump –-user [user name] –-password=[password] [database name] > [dump file]
+  
+
+ +Rename your old Tracks installation (e.g. to 'tracks-old') so that you can install Tracks 1.7 along side it. + +h4. Install the latest version of Tracks + +There are two methods of downloading Tracks: + +# (Recommended for most people) Download the "zipped package":http://bsag.bingodisk.com/public/files/tracks_1.7.zip, and unzip in your preferred location (e.g. @~/Sites@ for Mac OS X users). +# If you want to live on the edge, you can get the latest development version from GitHub using git (bear in mind that this may be less stable than the released versions): + +{% codeblock lang:bash %} +cd ~/Sites +git clone git://github.com/TracksApp/tracks.git +cd tracks +{% endcodeblock %} + + +h4. Copy over old configuration + +There are a few settings and configuration files you need to copy over from your old installation. If you copy them over rather than moving them, you can still run your old version of Tracks if anything goes awry with the installation process. + +# Copy @/config/database.yml@ from your old Tracks directory to the same location in the new one. Double check that the information there is still correct. +# Duplicate @/config/site.yml.tmpl@ in the Tracks 1.7 directory, and rename the file to @site.yml@. Open the file and alter the line @salt: "change-me"@ so that it matches what you had in the @environment.rb@ file in your old installation. You may also want to change the time zone setting as appropriate for your location. If you have made any other customisations to @environment.rb@ in the past, you can put them in your own configuration file (e.g. my-config.rb) in @config/initializers@. Please let us know it you think they should be in @site.yml.tmpl@. +# Copy your @/log@ directory over from your old installation to the root of the new one, or just rename @/log.tmpl@ to @log@ to start afresh. +# If you are using SQLite3, copy your database from @/db@ in your old Tracks directory to the same location in the new one. +# If you are using Windows, you may need to check the 'shebang' lines (@#!/usr/bin/env ruby@) [1] of the @/public/dispatch.*@ files and all the files in the @/script@ directory. They are set to @#!/usr/bin/env ruby@ by default. Check the format of those lines in your old installation, and change the new ones as necessary. + + +h4. Update your old database to the new format + +In a terminal, change directories so that you are inside the Tracks 1.7 directory. Then issue the command to update your Tracks 1.6 database to the format required for Tracks 1.7: + +{% codeblock lang:ruby %} +rake db:migrate RAILS_ENV=production +{% endcodeblock %} + + +Watch the output carefully for errors, but it should report at the end of the process that everything worked OK. If you do get errors, you'll have to fix them before you proceed any further. Running rake with the @--trace@ option can help to track down the problem. + + +h4. Start the server + +If you're still in the Tracks 1.7 root directory in a terminal, enter the following command to start up Tracks in production mode: + +{% codeblock lang:ruby %} +script/server -e production +{% endcodeblock %} + + +Visit the URL indicated by the output (e.g. @** Mongrel available at 0.0.0.0:3000@ +) in a browser, and with any luck, you should be able to log in and find all your actions as you left them! If you need to access Tracks from a mobile/cellular phone browser, visit @http://yourdomain.com/mobile/@. This mobile version is a special, lightweight version of Tracks, designed to use on a mobile browser. + + +h4. Clean up your old installation + +Once you're certain that your new Tracks 1.7 installation is working perfectly, you can delete your old Tracks directory. + +h3. Upgrading from versions prior to 1.043 + +The best option for versions prior to 1.043 is to follow the instructions below to upgrade to version 1.043, then use the instructions above to upgrade from version 1.043. + +# For safety, rename your current Tracks directory to 'tracks-old' or something similar. +# Before you do anything else, *BACK UP YOUR DATABASE* (tables and content) and keep the SQL dumps somewhere safe so that you can recreate the old database if necesary. +# Download a copy of Tracks 1.043 and unzip alongside your 'tracks-old' directory. +# Open the file @config/environment.rb@ and look at the last line which should read: @SALT = "change-me"@. Change the word change-me to something else of your choosing. This string will be used as a 'salt' to encrypt your password and make it a bit more secure. Also look at the timezone setting at the bottom. You can leave it commented out if your server is in the same time zone as you, but you may need to adjust it if your server is in a different time zone. +# In @database.yml@ insert your old database name, user and password under the 'development' section. If you are using SQLite3 rather than MySQL or PostgreSQL, you need only the database name, and to change the 'adapter' line to 'sqlite3'. You also need to copy (NOT MOVE!), your SQLite3 database from your tracks-old @db@ directory to your new tracks @db@ directory +# Run the command @rake extract_fixtures@ inside the Tracks directory. This will populate the @db/exported_fixtures@ directory with @*.yml@ files corresponding to the contexts, projects and todos table from the contents of your old database. +# Open @db/exported_fixtures/todos.yml@ and search for the lines starting @created:@ and replace with @created_at:@. If you are using SQLite3, you also need to change the following: @done: "0"@ with @done: "f"@ and @done: "1"@ with @done: "t"@. You need to replace the similar 'done' lines in @projects.yml@, and in @contexts.yml@ replace @hide: "0"@ with @hide: "f"@ and @hide: "1"@ with @hide: "t"@. +# Create a new MySQL database (named tracks1043, for example). In @database.yml@ insert this new database name, user and password under the 'development' and 'production' sections. If you are using SQLite3, insert a new name for a database to hold your Tracks 1.043 data. +# Run the command @rake db_schema_import@ inside the Tracks directory. This should import the upgraded schema for 1.043 into your new database. +# Run the command @rake load_exported_fixtures@ which will import the contents of your old database from the fixtures files in @db/exported_fixtures@. +# If you are using Windows, you may need to check the 'shebang' lines (@#!/usr/bin/env ruby@) [1] of the @/public/dispatch.*@ files and all the files in the @/script@ directory. They are set to @#!/usr/bin/env ruby@ by default. Check the format of those lines in your old installation, and change the new ones as necessary. +# Try starting up the server with @script/server@ to make sure that all your data has migrated successfully. If all is well, follow the instructions above to upgrade from version 1.043 to Tracks 1.6. If you need to access Tracks from a mobile/cellular phone browser, visit @http://yourdomain.com/mobile/@. This mobile version is a special, lightweight version of Tracks, designed to use on a mobile browser. + +fn1. The @env@ binary helps to locate other binaries, regardless of their location. If you don't have @env@ installed, you'll need to change this line to point to the location of your Ruby binary.