November 10, 2007

Preparing a Rails Application for SVN

The key for a rails application in SVN is to make sure not to check in stuff that is part of the run time. Rails could organize this better - but it is not so bad. This post describes how I did it. Here are some references:

Using svn propset

Howto User Rails With Subversion

My process is a variant of the above link.

First I check out my place in SVN that I want to add the application below. If I need to add a new directory - I make the directory and commit it.

Then I go into the empty directory and copy in my rails app.

Then I run these commands in the directory before checkin:

rm tmp/*/*
rm log/*
rm `find . -name '.DS_Store'`
rm `find . -name '*~'`
rm `find . -name '*.sqlite3' `
rake db:migrate VERSION=0

I just made a little script to do this so I don't forget steps.

Then I do an

svn add
svn commit -m "Initial commit"

Then after the commit I do a bunch of propsets

svn propset svn:ignore "*.log" log/
svn propset svn:ignore "*" tmp/sessions tmp/cache tmp/sockets
svn propset svn:ignore "*.rb\n*.sqlite3" db
svn propset svn:ignore ".DS_Store" .

svn commit -m "Setup initial ignores"

Edit your ~/.subversion/config and add this line:

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.sqlite3 schema.rb *.log


So folks can develop and not be bothered in their svn status output
when their running ruby system makes files.

If you want see all this cleverness in action - run the checked out app and then do this:

svn status --no-ignore

You will see something like this:

I log/development.log
I db/development.sqlite3
I tmp/sessions/ruby_sess.33f0133496165daf

Which means it is working.

Some Rails/SVN experts would suggest that you do not check in the database.yml and a few bits of public like dispatch.cgi and dispatch.fcgi.

Sure - I see the point there. But I erred on the side of making the developer's life easier and having a fully functional sqlite3 version when it comes out of SVN. Since we will have lots of developers and a fewer production instances - I figured that the right choice was to have production folks make the overlay rather than every single developer. Or perhaps make the overlay happen as part of the build of a release - which is a complex script anyways. Make it easy for the developer I always say.

Posted by csev at November 10, 2007 12:48 PM