Comments on: Setting up a new Rails project in Subversion http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/ So I don't have to figure things out more than once. Tue, 30 Sep 2008 23:40:36 +0000 http://wordpress.org/?v=2.6.2 By: Trey http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4147 Trey Fri, 29 Jun 2007 04:46:17 +0000 http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4147 <p>For the record, I've deleted my repository and started over using Rails 1.2.3 as you recommended. Luckily, I hadn't really started any work on it yet.</p> For the record, I’ve deleted my repository and started over using Rails 1.2.3 as you recommended. Luckily, I hadn’t really started any work on it yet.

]]> By: Trey http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4110 Trey Wed, 27 Jun 2007 04:57:04 +0000 http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4110 <p>I think I will choose option 2 for now.</p> I think I will choose option 2 for now.

]]> By: JTJ http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4109 JTJ Wed, 27 Jun 2007 04:46:26 +0000 http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4109 <p>I haven't used edge in a while. Didn't know they were doing .erb instead of .rhtml. I guess you have two options:</p> <ol> <li>Change your .erbs to .rhtmls</li> <li>Use option 2 from my previous comment and lock your project to the current trunk (r7136 at the time of this comment).</li> </ol> I haven’t used edge in a while. Didn’t know they were doing .erb instead of .rhtml. I guess you have two options:

  1. Change your .erbs to .rhtmls
  2. Use option 2 from my previous comment and lock your project to the current trunk (r7136 at the time of this comment).
]]> By: Trey http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4107 Trey Wed, 27 Jun 2007 04:32:10 +0000 http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4107 <p>Ah. That makes lots of sense. But what would you do if you already ran a bunch of </p> <pre><code>script/generate scaffold </code></pre> <p>(formerly scaffold_resource) and it created <strong>.erb</strong> instead of <strong>.rhtml</strong> files?</p> Ah. That makes lots of sense. But what would you do if you already ran a bunch of 

script/generate scaffold

(formerly scaffold_resource) and it created .erb instead of .rhtml files?

]]> By: JTJ http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4105 JTJ Wed, 27 Jun 2007 04:14:35 +0000 http://solutions.treypiepmeier.com/2007/06/25/setting-up-a-new-rails-project-in-subversion/#comment-4105 <p>If your svn:externals file says this:</p> <pre><code>rails http://dev.rubyonrails.org/svn/rails/trunk/ </code></pre> <p>Then, you're using edge rails, which will change often. Every time the Rails trunk gets a new changeset, your "svn update" command is going to download it, and you have no control over it.</p> <p>If your want to work with today's edge Rails (but not necessarily tomorrow's edge Rails), the best thing to do is lock your project to a specific revision of the trunk, you can specify it like this:</p> <pre><code>rails -r7136 http://dev.rubyonrails.org/svn/rails/trunk/ </code></pre> <p>Then, you can change the revision number whenever you feel that it is safe to do so. </p> <p>I personally prefer to use the official releases for production apps The official stable releases are found in the tags directory like:</p> <pre><code>rails http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-3/ </code></pre> <p>Finally, there is one more option. That is to lock your project to a specific <strong><em>major</em></strong> release, but get updates whenever there is a <strong><em>minor</em></strong> release. There are pros and cons to this method. On the plus side, you always have the latest bug fixes for your chosen release; on the down side, you don't ever know when an "svn update" is going to pull a new release of Rails into your project. I think it's best to use the previous method, and just edit your svn:externals whenever there is a minor release. They keep the latest stable release in a branch. Reference it like this:</p> <pre><code>rails http://dev.rubyonrails.org/svn/rails/branches/1-2-stable/ </code></pre> If your svn:externals file says this:

rails   http://dev.rubyonrails.org/svn/rails/trunk/

Then, you’re using edge rails, which will change often. Every time the Rails trunk gets a new changeset, your “svn update” command is going to download it, and you have no control over it.

If your want to work with today’s edge Rails (but not necessarily tomorrow’s edge Rails), the best thing to do is lock your project to a specific revision of the trunk, you can specify it like this:

rails   -r7136  http://dev.rubyonrails.org/svn/rails/trunk/

Then, you can change the revision number whenever you feel that it is safe to do so.

I personally prefer to use the official releases for production apps The official stable releases are found in the tags directory like:

rails   http://dev.rubyonrails.org/svn/rails/tags/rel_1-2-3/

Finally, there is one more option. That is to lock your project to a specific major release, but get updates whenever there is a minor release. There are pros and cons to this method. On the plus side, you always have the latest bug fixes for your chosen release; on the down side, you don’t ever know when an “svn update” is going to pull a new release of Rails into your project. I think it’s best to use the previous method, and just edit your svn:externals whenever there is a minor release. They keep the latest stable release in a branch. Reference it like this:

rails   http://dev.rubyonrails.org/svn/rails/branches/1-2-stable/
]]>