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.

Comments are closed.