ansaurus

Question

Looking for SVN Best Practices When Building Rails Applications on Ubuntu

Answer 1

+1 A:

Many people use piston or desert to manage plugins and install gems into Rail local vendor folder (stored under SVN).

http://www.rubyinside.com/advent2006/12-piston.html http://pivotallabs.com/users/brian/blog/articles/459-build-your-own-rails-plugin-platform-with-desert

I also recommend using geminstaller which will help you both install all the same gems and the same versions of them

http://geminstaller.rubyforge.org/

I use SVN from the command line but if you were more comfortable with TortiseSVN you might want to try IDEs that have SVN nicely integrated like RadRails and NetBeans. The IDEs have very similar graphical SVN managers similar to Tortise, if you want to work on the cmd line just find a simple 10 minute SVN tutorial and you should be good to go.

I have never heard of rapid SVN and the normal SVN tool has always worked just find with me, hardly ever causing the locking folders issue.

danmayer 2008-11-12 18:08:28

Answer 2

+4 A:

For plugins, I'd personally recommend just sticking them in the vendor folder and add them to SVN as if you'd written the code yourself. Piston was also a great solution, but switched away from it when all the common plugins started moving to github (piston has been unreliable since then)

For gems, hopefully you're using rails 2 or higher. You should be listing the gems you require in your config/environment.rb using config.gem. Here's a bunch of information about that feature

What this means is that if you add a new gem, the next time your co-worker updates, his rails app won't boot until he's got the neccessary gems. He can then install them in one step using sudo rake gems:install

You can take this one step further, and put your gems in the vendor directory. This is commonly known as "vendor everything." The easiest way to do this is to list all the gems you use in environment.rb as above, and then run rake gems:unpack. There are 2 problems with this approach however, so I prefer not to use it myself.

If you have 10 apps and they each vendor their gems, you end up keeping 10 copies of common gems in subversion, which makes updating all your sites a whole lot slower.
This may not be an issue for you, or may be worth putting up with, it's just a personal preference.
Some gems (such as mongrel or hpricot) have native extensions written in C. What this means is that when you install them, the .c source code is downloaded, and gcc gets run to compile it specifically for your system.
If you installed a native C extension on ubuntu, then put it in the vendor folder, and later on tried to run that on OS X (or even possibly a different version of ubuntu) it would most likely crash your ruby process and bring your app down.
If all your gems are pure-ruby ones, then this is not a problem, but it's just something to be aware of.

Orion Edwards 2008-11-12 20:24:16

I like this approach. Why can't gems be in the vendor folder too? I seem to recall seeing the rails gem in there on a screen cast i saw. I cold be mistaken though.

levi rosol 2008-11-12 20:28:08

Updated answer to explain :-)

Orion Edwards 2008-11-12 21:12:42

awesome, and thanks for the complete answer. How will i know what gems have native C extensions? I assume i just need to look at the code for them. I'm ok with the dev having to update mongrel and hpricot themselves (we're using both of those) as they are less likely to change from what i see.

levi rosol 2008-11-12 21:44:14

Answer 3

A:

Orion mentioned having to rebuild gems that have been vendored when sharing them between different OS's - you can use the gems:build rake task to rebuild them automatically.

Jon Wood 2008-11-13 10:32:21

Answer 4

A:

First, figure out svn from the command line. The svn-book is on line. It's not too hard to do svn status or svn commit -m "blah". Most problems come if you use OS functions to delete or rename files. Use the svn commands for that.

Next, if rapidsvn is not working out for you, try svn-workbench. Hate to say it, but none of the linux svn GUI tools that I have seen are as good as tortoisesvn.

Plugins and svn are an issue. There is a tool called piston that aims to clear that up, though I don't use it. I check out the plugins into my vendor/plugins directory. If a new version comes out that I really want, I use my trusty update_plugin bash script to update the plugin:

#!/bin/bash

#  reinstall the plugin in an svn friendly way
plugin="some_plugin"
plugin_url="http://some_server/some_plugin/trunk"

for f in site1 site2 site3
do
  echo $f
  cd ~/rails/$f

  svn delete vendor/plugins/$plugin
  rm -rf vendor/plugins/$plugin
  svn -m "remove $plugin" commit
  script/plugin install $plugin_url
  svn add vendor/plugins/$plugin
  svn -m "add $plugin" commit

done

2008-11-17 18:53:25

ansaurus

tags:

views:

answers:

Looking for SVN Best Practices When Building Rails Applications on Ubuntu

related questions