Movable Type Bleeding Edge Updates Via Subversion

| 2 Comments

Update: I’ve placed this upgrade script on the wiki, a better place for more people to enjoy and collaborate: wiki.movabletype.org/MT_Shell_Script_Installer

Below code is no longer cutting edge technology. =P

Follow these steps to easily switch between versions of Movable Type.

Requirements

  • Subversion - Movable Type development is kept in a version control system called Subversion. Subversion allow many developers to work on the same code at the same time.
  • shell access - I use Terminal.app on my MacBook Pro.

Development Branches

There is a branch for each development cycle. These branches are worked on for 1-3 weeks, before a branch is closed and passed to QA for testing. If QA finds any bugs, then bugs are fixed in the branch. All subsequent features are implemented in the next branch sequentially. The branch with the highest number is the most current release (as of this writing, release-35)

Stable Tags

Once a particular place in development is tested and approved for release the code at that point is tagged with a release number.

Checkout the Code

These steps will be a little different based upon the setup of the web hosting environment. Here’s a simplified example of how I set-up Movable Type:

www.beausmith.com/
    cgi/
        release-33/
        release-34/
        mt  -> release-34
        mt4.01
        mt4.11
    html/
        blog/
            (archives here)
        index.php
        mt-static -> ../../cgi/mt/mt-static

The items with the arrow -> are symlinks. These allow me to not have to change urls when I update to a new release and also allow me to keep my mt-static directory inside the release folder. When I want to update to release-35, here’s the steps I’ll take:

  1. Navigate to the cgi directory & use the subversion checkout command to get the latest version:

    $ pwd;
    /www.beausmith.com
    $ cd cgi;
    $ svn co http://code.sixapart.com/svn/movabletype/branches/release-35;
    
  2. Issue the make command to build the current release

    $ make;
    
  3. Make the support files writeable

    $ chmod -R 777 release-35/mt-static/support
    
  4. Remove the current symlink and create a new symlink to point to your release branch. I do this in the same step so as to avoid any potential downtime while switching.

    $ rm mt; ln -s release-35 mt;
    

That’s it! Go access you MT installation.

Updating

Since changes will be committed round the clock by the MT teams in San Francisco and Japan, you’ll want to update often to get the latest changes.

    $ cd cgi/release-35;
    $ svn up;
    $ make;

Doing a make is not necessary unless there are *.pre files that need to be rendered for the current language.

Note: If you make changes to the files in the MT code, they may conflict with the updated code. Look forward to a future article about Subversion basics.

Switching Between Movable Type Installs

Is there a bug in release-35 and you want to go back to the stable mt4.11 install? Easy. Remove the mt symlink and then create a new one pointing to the desired MT install:

    $ rm mt; ln -s mt4.11 mt;

View Changes & Code Diffs with Trac

Trac also makes it easy to browse through all the recent changes to any branch of Movable Type. Note the similarity & differences in the urls

  • trac: http://code.sixapart.com/trac/movabletype/browser/branches/release-35/
  • svn: http://code.sixapart.com/svn/movabletype/branches/release-35/

Questions? Please comment below.

2 Comments

Hey Beau,

Obvious question… what happens if there’s schema changes between the releases or between a tagged version of MT and one of the release branches? You’d be stuck on a possibly unstable branch of MT where the database schema has changed and I don’t see how you could just drop back without possibly breaking things.

A few answers….

  1. Never use beta code for critical projects.
  2. If something is significantly broken, it will get fixed shortly as a developer will most likely also find the same issue. If it’s critical, make sure there is a bug filed for the issue.
  3. If you have to revert, be sure to you have back up databases to make this easy. I always create a database dump before running this script. Duh, I should add the mysql dump to this script.
  4. I’ve been using the same database for the last 22 releases without any issues. I recall asking Brad about schema changes and him saying that they rarely have significant impact.
  5. I’ve never had a schema issue.

Leave a comment