The Path to Rails 3: Greenfielding new apps with the Rails 3 beta

Upgrading applications is good sport and all, but everyone knows that greenfielding is where the real fun is. At least, I love greenfielding stuff a lot more than dealing with old ghetto cruft that has 1,900 test failures (and 300 errors), 20,000 line controllers, and code that I’m pretty sure is actually a demon-brand of PHP.

Building a totally new app in Rails 3 is relatively simple (especially if you’ve done it in previous Rails versions), but there a few changes that can trip you up. In the interest of not missing a step someone may need, this post is a simple walkthrough of building a new app with Rails 3. I would have simply posted about the Rails 3 version of the Getting Started guide, but it’s actually a bit out of date now. I’ve committed each step in its own commit on Github so you can step through it (the repository is here: http://github.com/jm/rails3_blog)

An aside: Installing the Rails 3 beta

Installing the Rails 3 beta can be sort of tricky since there are dependencies, it’s a prerelease gem, and RubyGems basically poops the bed when those two scenarios collide. Hopefully that’ll be fixed soon, but the mean time, install Rails’ dependencies like so:

gem install rails3b
gem install arel --pre

# or if that gives you hassle...

gem install i18n tzinfo builder memcache-client rack \
            rack-test rack-mount erubis mail text-format thor bundler

Once all those lovely gems are installed (add --no-ri and --no-rdoc if you want to skip those/speed up your install), then install the prerelease version of Rails:

gem install rails --pre

Now you’re ready to roll on with the Rails beta!

Using the new generator

The application generator is basically the same with two key differences:

The parameter that was formerly the app name is now the app path. You can still give it a “name,” and it will create the folder like normal. But you can also give it a full path (e.g., ~code/my_application rather than just my_application) and it will create the application there.
All parameters for the generator must go after the app path. So, previously one could do rails -d mysql test_app, but now that has to be rails test_app -d mysql. This change is largely due to the major refactoring of the Rails generators, so even though it’s somewhat of a temporary annoyance, it’s definitely worth it for the flexibility and power that the new generators bring (more on that soon).

So, let’s generate a blog application (really original, I know, right?):

rails rails3_blog -d mysql

If you get an error like “no value provided for required arguments ‘app_path’”, then you’ve gotten your parameters out of order. If you’d like to use another database driver, you can provide postgresql or sqlite (or nothing, since sqlite is the default). You’ll see a lot of text scroll by, and now we have a nice, fresh Rails 3 application to play with [4b6b763ac9378c6cde95b0815d2a4c2619a0e403].

Let’s crank up the server (note that it’s different now!)…

rails server

Rails went the “Merb way” and has consolidated its many script/* commands into the rails binscript. So things like generate, server, plugin, etc. are now rails generate and so on. Once the server’s booted, navigate over to http://localhost:3000 and you should see a familiar friend:

You're on board!

Click on “About your application’s environment” to see more information about the app you’ve generated.

Configuring an app

Now comes the task of configuration. Again, not a whole ton of changes from previous versions, but navigating them can trip up the novice and journey(wo)man alike. First, setup all your database settings in database.yml; it’s just like previous versions of Rails, so no surprises there (and plenty of information abounds if you’re new to it).

Next, pop open config/application.rb. This is where much of the configuration information that once lived in config/environment.rb now lives. The portion you probably want to pay attention to most when making a new application is the block that defines your options for ORM, template engine, etc. Here’s the default:

config.generators do |g|
  g.orm             :active_record
  g.template_engine :erb
  g.test_framework  :test_unit, :fixture => true
end

I’m going to stick with the defaults, but you could substitute in something like :datamapper or :sequel for :active_record, :haml for :erb, or :rspec for :test_unit (once they get it working with Rails 3). Doing so will set the generators for models, views, etc. to use your tool of choice (remember that whole technology agnosticism thing?); I don’t know if all these generators are available yet, but there are some available here.

The config/application.rb file also houses some configuration for other things.

If you need to configure internationalization, it’s been moved to application.rb. Rails 3 comes equipped with a really powerful i18n toolkit; if you haven’t seen it, you can learn a little more about it here. The defaults that Rails sets up will work for most people (default locale is en and all translations in the default directory are automatically imported), so you may not need to touch anything, but if you need to customize, this is the place to do it.
You may want to set a default timezone. I usually stick with UTC since it’s easy to convert on a per-user basis to their desired timezone, but you might want to set it your timezone or the server’s timezone.
Your favorite old haunts from config/environment.rb such as config.plugins, config.load_paths, etc. are still there (even though config.gems is not).

Other configuration bits like custom inflections, mime types, and so on have been moved out into their own initializers that you can find under config/initializers. [b613cef6f92ff7d3304da84dba530196ba51371d]

The last big piece of configuration you’ll need to add is a Gemfile for bundler (get more information on Gemfiles and bundler here and here). We already have a basic Gemfile that has the following:

# Edit this Gemfile to bundle your application's dependencies.
source 'http://gemcutter.org'

gem "rails", "3.0.0.beta"

## Bundle edge rails:
# gem "rails", :git => "git://github.com/rails/rails.git"

gem "mysql"

## Bundle the gems you use:
# gem "bj"
# gem "hpricot", "0.6"
# gem "sqlite3-ruby", :require => "sqlite3"
# gem "aws-s3", :require => "aws/s3"

## Bundle gems used only in certain environments:
# gem "rspec", :group => :test
# group :test do
#   gem "webrat"
# end

Notice that it has added mysql as a dependency since that’s what we set as the database (or whatever driver you selected, for example, pg or sqlite). Since I want to write blog entries in Markdown, I’m going to add rdiscount as a dependency. To do so, I simply have to add this:

gem "rdiscount"

As I’ve said before, bundler is much more powerful than config.gem, and one of the great features it adds is the concept of a gem “group.” For example, let’s say I want to use mocha, but only when testing (obviously). You would add this to your Gemfile:

group :test do
  gem "mocha"
end

Now this gem will only be added in when testing. This will also be useful for production only gems related to caching and what not. [598652fa49634eaa9d23ab8df652faf73dfd07f4]

Next, run bundle pack if you want to vendor everything or bundle install to install the gems to system gems. After you’ve combed through this stuff and set whatever you need, you’re done configuring your application. Now on to actually building something.

Building it out

So, we’re going to build a very simple blog (and expand it later). First, let’s generate a scaffold for posts, since that’ll generate a lot of boilerplate code that we’ll go back and tweak:

rails generate scaffold post title:string body:text
      invoke  active_record
      create    db/migrate/20100202054755_create_posts.rb
      create    app/models/post.rb
      invoke    test_unit
      create      test/unit/post_test.rb
      create      test/fixtures/posts.yml
       route  resources :posts
      invoke  scaffold_controller
      create    app/controllers/posts_controller.rb
      invoke    erb
      create      app/views/posts
      create      app/views/posts/index.html.erb
      create      app/views/posts/edit.html.erb
      create      app/views/posts/show.html.erb
      create      app/views/posts/new.html.erb
      create      app/views/posts/_form.html.erb
      create      app/views/layouts/posts.html.erb
      invoke    test_unit
      create      test/functional/posts_controller_test.rb
      invoke    helper
      create      app/helpers/posts_helper.rb
      invoke      test_unit
      create        test/unit/helpers/posts_helper_test.rb
      invoke  stylesheets
      create    public/stylesheets/scaffold.css

Next, run rake db:migrate to create the database table for Post. Now if you go to http://localhost:3000/posts, you should see the standard scaffold interface. [8f27fe53282de70343afadaedd583ecc279d535d]

Let’s a take a look at the controller code; you’ll see a lot of actions that look sort of like this:

def show
  @post = Post.find(params[:id])

  respond_to do |format|
    format.html # show.html.erb
    format.xml  { render :xml => @post }
  end
end

That’s some clean code, but in Rails 3, we can compress down even further with the Responder. This class wraps very common rendering logic up into some really clean helpers. To use it, you’ll need to add what formats your actions respond with to the class:

class PostsController < ApplicationController
  respond_to :html, :xml

  .
  .
  .
end

So your show action goes from the above to this:

def show
  @post = Post.find(params[:id])

  respond_with(@post)
end

Now the action will automatically look at the state of the object, the format requested, and respond accordingly. So, for example, if you successfully create an object in create, it will redirect to show; if it fails, it will render new (this is assuming, of course, you’re requesting HTML). Of course, if you need custom logic, you’ll want to do something else, but these helpers make already clean, RESTful code even easier and cleaner. Make sure to rake to make sure you refactored it right! [53846f92393e10146fbf2d9b43b530a244d0137e]

Next, open up config/routes.rb. It should look something like this (with oodles of extra commented out routes):

Rails3Blog::Application.routes.draw do |map|
  resources :posts
end

To set PostController’s index action to the root, we need to do two things. First, remove public/index.html otherwise it’ll always overtake any root route you set. Next, add a root route to config/routes.rb like this:

Rails3Blog::Application.routes.draw do |map|
  resources :posts

  root :to => "posts#index"
end

Now going to http://localhost:3000 should show the posts index page. [120c377c8ec1c138d600f9b9bc39bedf1d43afd4] OK, so now that most of the functionality is in place, let’s make it look presentable; here’s my version of the index template:

<% @posts.each do |post| %>
  <h2><%= link_to post.title, post %></h2>
  <p>posted at <%= post.created_at.strftime('%D') %></p>
  <p><%= post.body %></p>
<% end %>

<%= link_to 'New post', new_post_path %>

You can see what other design edits I made in this commit [03b2c39d65331f7dfeb4ada89cf65604f7130e2d].

Now we need to add the Markdown functionality to the Post model. First, let’s generate a migration [2cbb0b04411ac1712a4f5039ed93bdad0cb6e76e]:

rails generate migration AddRenderedBodyToPosts rendered_body:text

Migrate your database, and now we’re ready to move on to testing. Write a simple test to make sure it renders the body after a save [af83a5a2e85a1679896e989f6828d1f5ee4aa7d3]:

require 'test_helper'

class PostTest < ActiveSupport::TestCase
  test "renders Markdown after save" do
    post = Post.create(:title => "This post rocks.", :body => "Now *this* is an awesome post.")

    assert_equal "<p>Now <em>this</em> is an awesome post.</p>", post.rendered_body.chomp
  end
end

If you rake now, that test should fail. So, let’s make it pass:

class Post < ActiveRecord::Base
  before_save :render_body

  def render_body
    self.rendered_body = RDiscount.new(self.body).to_html
  end
end

You should be all green [4730cd4e8601c74a05b9763d307b462f76e44b26]! Now we’ll need to go back and change the instances of body to rendered_body on the index and show views.

That’s pretty standard Rails stuff, so let’s do something Rails 3-specific now. First, let’s add some validations; we’ll want to make sure that every post has a title and a body.

test "requires title" do
  post = Post.create(:body => "Now *this* is an awesome post.")
  assert !post.valid?
  assert post.errors[:title]
end

test "requires body" do
  post = Post.create(:title => "This post rocks.")
  assert !post.valid?
  assert post.errors[:body]
end

Note the new API for Active Record errors (i.e., [] rather then on) [930e8868b0e4d8904d6f5090f6b445b0c428f71f]. Now, of course, we have to make them pass…

class Post < ActiveRecord::Base
  before_save :render_body

  validates :title, :presence => true
  validates :body, :presence => true

  def render_body
    self.rendered_body = RDiscount.new(self.body).to_html
  end
end

As you probably noticed, the API for Active Record validations I’ve used here is different (the validations shown are equivalent to a validates_presence_of validation, which are still around) [178bb06839bb44978f42c922c9348bfe783da8b1]. You can read a little more about the new style of validations here. So, now if you try to create a post without a title or body, it’ll reject it.

More later…

I realize this introduction is extremely simple, but I’ll expand on it very soon (including authentication, commenting, post drafts, an API, spam protection, feeds, caching, etc. with a separate entry after it on deployment). I’ll get to that sort of stuff very soon, but my next post is going to be a walkthrough of upgrading an app step by step (very similar to this entry). Look for it in a few days!

Comments

permalink

Using Subversion with Xcode 3
on Mac OS X Leopard

Developers of even the easiest-to-use applications know that manually managing a project's set of source files is no simple task. Most serious developers depend instead on a source control management (SCM) system to handle the intricacies of source file versioning, collaboration, and storage. Xcode 3.1 makes SCM simple by including a well-integrated, common interface to three widely used source control systems, one of which is the popular Subversion SCM.

Subversion is a free, open source solution suitable for environments of from one developer to thousands. Best of all, Mac OS X 10.5 Leopard includes everything needed for a developer to easily create a complete Subversion server to use with any Xcode project. Not only is every Mac well-equipped to provide Subversion server capabilities right out of the box, but the free Xcode IDE is designed specifically to work with Subversion.

Subversion can run either as a standalone server process or from the Apache web server using the Subversion module. This article will demonstrate both methods, using Mac OS X Server 10.5 for the latter, and then show how to get started managing your source files with Subversion from within Xcode 3.1.

This is an update to the previous Getting Control with Subversion and Xcode article, which outlines a procedure for installing an Apache server that while appropriate for Tiger, requires software downloads and extensive use of the command line. Leopard Server eliminates the need for these steps, allowing you to get an Apache Subversion server up and running within minutes, using GUI tools almost entirely

Using SCM

Source control management systems, also known as version control or revision control systems, track and preserve the entire change history of a project's files. Using such a system, developers can easily revert files to previous versions, maintain multiple branches of a project, and work simultaneously on the same project with other developers. Typically, these systems require developers to check out files from a central repository before working with them and to commit their changes back when done. The system accurately merges any changes that multiple developers might have made to the same file, prompts developers to manually resolve any conflicts, and stores the file changes efficiently to disk.

Xcode 3.1's built-in SCM interface lets you perform these SCM procedures without leaving the program. Using the Subversion client from within Xcode, you can check out and commit your files, compare and revert changes, and move files in and out of source control. For complete details on using Xcode's SCM support see the Xcode Source Management Guide.

Subversion Server Types

Before setting up a Subversion server, you'll need to decide whether to run it using the svnserve server binary or from Apache using the mod_dav_svn module. Both servers work with clients and repositories in the same way and are indistinguishable from that perspective. The servers do differ, however, in their scalability, performance and ease of installation. While either server can be made to work for most situations, the following general recommendations will help you decide which is best for your environment.

`svnserve`

The svnserve server is the best choice for smaller environments, where mulit-user management, logging and access from outside the firewall are not large concerns. svnserve comes pre-installed on Leopard, and getting it up and running requires almost no additional steps nor Mac OS X Server. Also, svnserve provides better network performance of the two server types.

Run in its default configuration, however, svnserve lacks any real security; it transfers its data unencrypted across the network and stores user passwords in plaintext on the server. To mitigate these issues, you can easily run svnserve over ssh, and this article will detail that procedure. Still, ssh requires users to have shell accounts on the server, so if that is a concern, svnserve over ssh is not a good solution.

Apache (`mod_dav_svn`)

Running subversion from Apache, on the other hand, is the better choice for larger environments, where mulit-user management, logging, and access from outside the firewall are important factors.

As you'll see, Leopard Server gives you all the software and administration tools needed to run a large-scale Apache Subversion server. Providing access is as simple as using the Workgroup Manager application to add an account, and the Server Admin application lets you finely control access to the repository, view the access logs, and manage your SSL certificates.

The mod_dav_svn module is actually an extension to the WebDav module (mod_dav), so using it provides all the benefits of managing users and permissions with the Server Admin application's easy-to-use WebDav tools. Apache's own logging allows you to track and troubleshoot the Subversion transactions. And to ensure adequate security, you can configure Apache to run over SSL, a step which this article details as well. Also, as an added benefit, Apache provides a web interface to your source files with no additional configuration.

These capabilities, however, come at a cost of network performance and ease of installation. svnserve provides a stateful connection for its clients, therefore once a connection is established, Subversion commands get handled consecutively until you disconnect. Web connections, on the other hand, require more frequent connects and disconnects, and this overhead results in generally slower transactions.

Configuring the Apache server requires several more steps then configuring the svnserve server. While neither configuration requires any additional downloads or extensive use of the command line, setting up Apache the first time could take up to 30 minutes, while getting the svnserve server going shouldn't take more than five.

You can find a thorough comparison of the two server types on this svnbook page, which is part of the complete online Subversion documentation, Version Control with Subversion.

Creating a Subversion Repository

Regardless of which server you choose to use, the first step of setting up a repository is the same.

The repository stores the files that you want to keep under version control and also holds the change data needed to produce a copy of a file from any point in its lifetime. When you check out your project from the repository, the server makes a working copy of the project on your computer where you can work with it as you do with any project. Whenever it's time to commit your changes, the server calculates those changes and writes them back to the repository. Since only the changed information is copied, the repository can store many versions of a file using much less disk space than if it had to keep complete file copies.

You will need to create your repository and project directories using command-line tools, but once that's done, you can interact with the repository using only Xcode. To begin, open Terminal on the server (or use ssh to connect to it) and enter this command to create Subversion and Repository subdirectories in /Library (though you can put them anywhere the web server has access):

mkdir -p /Library/Subversion/Repository

Next, use the Subversion administration tool to create the project directory itself (named Project1, in this case), and populate it with the subdirectories and files it needs to work in a repository:

svnadmin create /Library/Subversion/Repository/Project1

Before you can import the project files using Xcode, you'll need to import an empty directory skeleton into the project directory using the command line. These directories compose Subversion's standard project layout: a top-level directory named for the project and its three subdirectories named trunk, branches, and tags. Create these temporary directories in /tmp with this command:

mkdir -p /tmp/Project1/trunk /tmp/Project1/branches /tmp/Project1/tags

Import the directories into the repository with this command:

svn import /tmp/Project1/ file:///Library/Subversion/Repository/Project1 -m "Initial import"

You can then delete the temporary directories:

rm -rf /tmp/Project1

Finally, restrict permissions on the repository directories to ensure that only the web server (if you'll be using the Apache server) and members of the admin group have access:

sudo chown -R www:admin /Library/Subversion/Repository
sudo chmod -R ug+rwX,o= /Library/Subversion/Repository

If you'll only be using the svnserve server, you can make the repository root-owned with these commands instead:

sudo chown -R root:admin /Library/Subversion/Repository
sudo chmod -R ug+rwX,o= /Library/Subversion/Repository

Running the `svnserve` Server

If you've chosen to use the svnserve server over ssh, there isn't even a step two. The svnserve binary comes pre-installed on Leopard, and the ssh server (sshd) launches svnserve on demand, so svnserve doesn't need to run as a daemon. Therefore, as long as the repository is in place, and sshd is running on the server, svnserve will already accept connections. Skip ahead to the section, Using Subversion from Xcode to get started with your first project.

Note: To start sshd on the server, open System Preferences, select the Sharing icon and select the Remote Login checkbox.

Otherwise, go on to the next section, Configuring the Apache Server.

Configuring the Apache Server

Configuring an Apache Subversion server on Mac OS X Server requires quite a few more steps, but all are fairly simple. Begin by opening Server Admin and connecting to your server. If the Web service is not yet in the list of services, select Add Service from the Server menu, click to check the Web service checkbox, and click Save (Figure 1). You don't need to start or restart the Web service until you've completely configured the Subversion server.

Turning On the Web Service

Figure 1: Turning On the Web Service

The next step is enabling the Subversion Apache module. This module, mod_dav_svn, relies on the web_dav module, which gives Apache filesharing-like capabilities. Together, these modules provide Subversion clients with read and write access to Subversion repositories using only the HTTP protocol, thereby simplifying server and network administration.

To enable the module, select Web from the services list at left, click Settings from the toolbar, and then select the Modules tab. Find the dav_svn_module in the list, click its checkbox on, and then click save (Figure 2). You don't need to enable the authz_svn_module, as you'll instead be using directory services for authentication. Also WebDAV is turned on elsewhere, so you don't need to enable its module here either.

Enabling the SVN Module

Figure 2: Enabling the SVN Module

With the Subversion module enabled, Leopard Server and Apache work with the repository much like any other WebDAV site they're serving, so configuration is largely identical. To start, create a new secure website by first clicking Sites in the toolbar, and then clicking the Add (+) button. This creates a new Apache virtual host, which defines a unique hostname or port (or both) and document root for each site. Once it's created, enable the site using the checkbox in the new site's listing.

If you're hosting only the Subversion site, the following steps will work fine. If you're already hosting other sites on your server, you might need to consult the Web Technologies Admin guide to learn how to make the new site work alongside your existing site(s). Generally, as long as the new site has a unique hostname or port that site should operate properly.

As shown in Figure 3, configure the new site by selecting the General tab and making these settings:

Domain Name: If you have a fully qualified domain name, you can enter that here. Otherwise, it's fine to keep this blank.
Description: Enter any descriptive text you would like here, or keep it blank.
IP Address: Set this to "any"
Port: Set this to 443, the default port for secure web traffic (SSL), which you will be enabling in an upcoming step.

Configuring the Site

Figure 3: Configuring the Site

Leave the remaining settings at their defaults, and select the Options tab. Enable WebDAV here, turning on the module that the SVN module depends on (Figure 4).

Enabling WebDAV

Figure 4: Enabling WebDAV

Select the Security tab and enable SSL, using the default certificate or your own if you have one (Figure 5). You'll want to use SSL for an important reason: Subversion requires authentication for access to the repository, and since Xcode uses the HTTP basic authentication method, your password would otherwise be sent across the network in an easily decoded format. With SSL enabled, the entire HTTP session is encrypted, keeping your password and all other transmitted data inaccessible to any network eavesdroppers.

Enabling SSL

Figure 5: Enabling SSL

Next, click the Realms tab to define a WebDAV realm for the repository. WebDAV uses this realm definition to determine what directories to share and with what permissions. Click the Add (+) button below the Realms list to create a new realm, and configure it with these settings, as shown in figure 6:

Realm Name: Give it a relevant name, "subversion", for example.
Authentication: Choose Basic.
Folder/Location Pop-up menu: Select Location and enter /svn/ in the field. Doing this directs an /svn/ URI (that part of the URL following the hostname) to the SVN module instead of a directory. In an upcoming step, you will configure that location with the actual repository path.

Click OK to save the definition.

Configuring the Realm

Figure 6: Configuring the Realm

Click the Add (+) button under the Users & Groups list to open the Users and Groups panel. For each account and group that you want to provide with repository access, drag its name from the panel to the Users & Group list and set its permissions in the list to Browse and Read/Write WebDAV. (If you need to add new accounts or configure groups, use the Workgroup Manager application to do so.) Ensure that the permissions for the Everyone group stay at None (Figure 7).

Adding Users to the Realm

Figure 7: Adding Users to the Realm

Finally, click Save to save the new site. Before you start (or restart) the Web service, there is one more command-line step that remains to be completed.

Leave Server Admin as it is and return to Terminal. Use a text editor to open the /etc/apache2/sites/0001_any_443_.conf file with root privileges:

sudo vi /etc/apache2/sites/0001_any_443_.conf

Note: If you did configure your site with a domain name, that name will appear in the filename just before .conf, as in 0001_any_443_tosxserver.west.lan.com.conf, for example.

Find the /svn/ location block near the end of the file and add these two lines just below the <Location "/svn/"> line, as shown in Figure 8:

DAV svn
SVNParentPath /Library/Subversion/Repository

The first line, then, directs that the Subversion module receives the /svn/ URIs (by way of the WebDAV module), and the second passes the repository path to the module.

Note: Some configuration changes you subsequently make to this site with Server Admin can cause the first line to revert to DAV no. If you do experience problems accessing the repository, check for this reversion, and if needed, correct the file and restart the web service.

Editing the Site's Apache Configuration File

Figure 8: Editing the Site's Apache Configuration File

With the edits complete and the file saved, return to Server Admin, select Web in the services list, and click Start Web. (If the web service was already running, click Restart in the prompt, or select Web in the services list and from the Server menu select Restart Service.)

The Subversion server configuration is now complete and ready to test in a web browser with this URL:

https://your.hostname/svn/Project1

Once authenticated to the repository, you should be able to browse the three empty directories you created there, as shown in Figure 9.

Browsing the Repository

Figure 9: Browsing the Repository

You're now ready to use Xcode to import a project directory.

Using Subversion from Xcode

The procedure for connecting from Xcode to either type of Subversion server is mostly the same; you'll see the slight differences included in the following steps. To begin, open Xcode and create a new project as usual, saving it to the desktop as Project1. In this example, the project is for a Cocoa application.

Typically, you wouldn't need to keep your build directory under version control, so confirm that this project has a separate location for it. From the Project menu, select Edit Project Settings, and set the build directory to a location outside of your project directory, as shown in Figure 10.

Relocating the Builds Directory

Figure 10: Relocating the Builds Directory

Next, create the Xcode repository settings for the project. From the SCM menu, select Configure SCM Repositories, and the SCM pane of the Xcode preferences panel will appear. Click the Add Repository (+) button and in the sheet that appears, name the Repository Project1, set the SCM System pop-up menu to Subversion, and click OK.

If you are connecting to an svnserve server, complete the repository settings as shown in Figure 11, using a URL in the form of:

svn+ssh://accountname@hostname/Library/Subversion/Repository/Project1

If you are instead connecting to an Apache server, complete the repository settings as shown in Figure 12, using a URL in the form of:

https://accountname@hostname/svn/Project1

Note: The URL for an svnserve server connection requires the absolute path to the project directory in the repository, while the Apache connection requires only the URI to that directory.

In either case, except for the password, the remaining fields should properly auto-fill with data from the URL. Enter the password and click Apply. When the status indicator shows "Authenticated", click OK to close the Preferences window.

Connecting to the Repository Using svnserve

Figure 11: Connecting to the Repository Using svnserve

Connecting to the Repository Using Apache

Figure 12: Connecting to the Repository Using Apache

You're now ready to import the project directory into the repository following these steps, as illustrated in Figure 13:

From the SCM menu, select Repositories.
Using the Repository browser that appears, select the trunk directory of the new Project1 repository.
From the browser's toolbar, click the Import icon.
Navigate to the Desktop and select the Project1 directory.
Add a comment to log with the import and click Import.
From the sheet that appears confirming the import, click OK.

Importing a Project to the Repository

Figure 13: Importing a Project to the Repository

If you're connecting to an Apache server, you can confirm the import with a web browser by re-loading the repository URL and browsing to the project directory, as shown in Figure 14.

Browsing the Imported Project

Figure 14: Browsing the Imported Project

Once the project directory is in the repository, you will no longer need the copy that's on the desktop. Instead, you will check out the project from the repository, a process that puts the actual working copy of that directory on your computer. Before you check out the project, then, quit Xcode and delete the Project1 directory from you desktop.

When you're ready to check out the project directory, re-launch Xcode and follow these steps, as shown in Figure 15:

Return to the Repository browser using the SCM > Repositories Menu command.
Using the browser, navigate to the Project1 > trunk > Project1 directory and select it.
From the browser's toolbar, click the Checkout icon.
Navigate to your normal location for keeping project directories and click Checkout.
Once the checkout is complete, click to open the Xcode project file when prompted.

Checking Out the Project

Figure 15: Checking Out the Project

At this point, nothing in the project itself yet indicates that it's under version control, so the final step is turning on SCM for the project:

From the Project menu, select Edit Project Settings.
On the Project Info palette that appears, find the SCM settings pop-up menu.
Select the Project1 (Subversion) repository from the menu, as shown in Figure 16, and close the palette.

Configuring SCM for the Project

Figure 16: Configuring SCM for the Project

Testing SCM

You should now be able to make changes to your project, see what files have changes, and then commit those changes back to the repository. Practice by making a change to one of your project files and saving it. To see what files have changes, enable the SCM column in either of the project window's list areas by right clicking in a header area and selecting SCM from the menu. The SCM columns will show an M for the file that was modified, as shown in Figure 17 (If the status doesn't show, from the SCM menu, select Refresh Entire Project.)

Enabling the SCM Columns

Figure 17: Enabling the SCM Columns

You can also compare the changes side-by-side by right-clicking the changed file's name and selecting Compare from the menu (see Figure 18). A window will appear with the changed lines highlighted, as shown in Figure 19.

Opening the Compare Window

Figure 18: Opening the Compare Window

Comparing the Changed Versions

Figure 19: Comparing the Changed Version

Once you've made your changes, commit them back to the repository by right-clicking the filename and selecting Commit Changes. Add a comment for the log and click Commit (Figure 20). Or you can commit several files at once using the SCM > Commit Entire Project command.

Committing the Changes

Figure 20: Committing the Changes

When you're finished using Xcode, close the project normally; when you're ready to work with it again, open it normally as well. The project continues to stay checked out, and you can continue committing your changes.

This is only the beginning of what you can do with Xcode's SCM system, now that you have a working Subversion server. To go further, refer to the Source Management Overview.

Updated: 2009-02-17

Resources

Evan
January 3, 2010 at 7:36 pm

Truly amazing…. Those creative ideas giving us more space to work with even better spirit… thanks to share.

Anol
January 3, 2010 at 8:30 pm

Great examples. I’ve written a whitepaper on Infographics for Marketing & Communication. Please take a look. (sorry for the shameless self promotion) http://www.getitcomms.com/pdf/Whitepaper_Infographics.pdf

Yigit Ozdamar
January 4, 2010 at 12:51 am

Nice post! Customer’s Mailstream is the best one i think…

Connie
January 4, 2010 at 1:31 am

very awesome, the assasination of Martin Luther King beside Schumacher versus another car racer…

you guys have no sense for decency

Lun
January 4, 2010 at 6:05 am

nice one, really!

Mike
January 4, 2010 at 6:59 am

These are terrific! I think its funny when people say design is not art. These infographics are used to visually display data, but I would definitely hang one in my office as art!

Vaskar
January 4, 2010 at 8:26 am

I definately liked it. Those pictures definately say lot of things. Most elated with the infographic depicting the train…..wow!

Giacomo
January 4, 2010 at 9:42 am

I would point out the infographics of Francesco Franchi, an Italian graphic designer: http://www.flickr.com/photos/ffranchi/4169684981/sizes/l/

visualhaze
January 4, 2010 at 1:17 pm

Bella raccolta, bravo Antò!

Marfi
January 6, 2010 at 2:13 am

Great infographs, thanks for the inspiration, feel free to check and this nice collection: http://favit.com/infographs – updated daily for even more inspirations and ideas :)

ajeshks
January 8, 2010 at 2:48 am

Very inspirational and great ideas…. :) thank you very much

Alex Lee
January 8, 2010 at 12:54 pm

Thanks for including my cycling stats. But I feel a little outclassed in such illustrious surroundings!

MB
January 17, 2010 at 8:36 pm

This is awesome! Thanks for the post. :)

Frank Matuse
January 31, 2010 at 8:43 am

Gosh. Awesome collection. I really enjoy to “read” the visualizations. Thank you Antiono.

6 Responses to “25 Creative E-Commerce Website Designs”

Jana Schweiss February 9th, 2010

Great picks! I love Green Label Organics – So simple, effective & creative!

aledesign.it February 9th, 2010

Is really amazing this post! There so many ideas! i’m so confused! I’m happy for this examples..Really good! Green Label Organics, mom & popcorn and benestar re my preferite!

alfiks February 9th, 2010

The affair looks quit interesting, not the best solution for e commerce, but however very creative.

[ del.icio.us poetry ]

customer helpline

1300 SWITCH

Compare, switch and save on your bills!

Gas & Electricity

Home Phone

Broadband

Jackgreen unplugged:

Premium Wordpress Themes

what you get

recently added wordpress themes

from the blog

twitter updates

stay connected

Making Time Machine work with the ReadyNAS

Introducing Memeo Backup Premium

TheTechStop.net reviews the ReadyNAS NVX

See the ReadyNAS Vault in action!

What’s a NAS?

Simplify remote access with ReadyNAS Remote

Archives

Recent Posts

Javadoc Tool

omgbloglol

An aside: Installing the Rails 3 beta

Using the new generator

Configuring an app

Building it out

More later…

Save Time, Gather & Download your URL´s Relevant Data

Enter Domain Name:

Search Engines

Social Networks

Extra Information

Search

quick search ( indexed info )

Browse

quick browse ( indexed info )

Flowplayer - flash video player for web

Email this video

Embed this video

Extend Flowplayer with Plugins

Display video data from different sources

Something new for the Flash world

Join the Flowplayer team

Flowplayer 3.1.4 released

jQuery Tools 1.1.2. is out

Popular posts

45 most recent posts

Search the site

Don't miss a thing

From the bookstore

Sponsor Logo Design Love

Inspiration elsewhere

Using Subversion with Xcode 3 on Mac OS X Leopard

Using SCM

Subversion Server Types

svnserve

Apache (mod_dav_svn)

Creating a Subversion Repository

Running the svnserve Server

Configuring the Apache Server

Using Subversion from Xcode

Testing SCM

Related Articles

Resources

From the Knowledge Network

IET Knowledgebase

I want to:

Quick finder for:

Peliculas Online, Cine Gratis, Peliculas, Estrenos online, Estrenos 2009

Generos

Ultimas peliculas SUBIDAS

American Pie 7

Meet the Spartans

The Incredible Hulk

Motherhood

Invictus

Taking Chances

Assassination of a High School President

Using Subversion with Xcode 3
on Mac OS X Leopard

`svnserve`

Apache (`mod_dav_svn`)

Running the `svnserve` Server

Anime Online - Animes - Anime Gratis - Naruto Shippuden
naruto shippuden 147 Sub Español Estreno: 07 de enero