Using textmate

Textmate has a text bundle which contains a command to remove trailing whitespace. This can be combined into a save macro, so that every time you save a file it has its trailing whitespace removed. Only problem is that I can't assign (cmd-s, OSX default save) to this macro, so I have to remember to use my new key combination (which sucks).

Using find to clean up everything

Find is so damn dangerous, especially when your getting it to execute an action which changes files, so you really have to be very careful with the following commands. I completely trashed a local git repository on my way to getting these commands working, and you could do worse!

Remove trailing spaces from selected file types

Because find is so dangerous I've taken the approach of including the files I want, rather than trying to exclude files.

find . -type f  -regex './.*rb' -or -regex ./.*feature -or -regex ./.*haml -print0 |xargs -0 sed -i .bak -E "s/[[:space:]]*$//"

The sed command creates backup files for each file it changes you can get rid of these using the following

find . -type f -regex ./.*bak -print0 | xargs -0 rm

This approach seems to work, but I'm not very happy with it. Its trail and error bash hackery, using two commands I don't understand properly (find and sed) and its prone to catastrophic mistakes if you mistype.

Using Git to cleanup

Git has a number of whitespace options which I don't understand. From what I've read so far I think the safest approach is to let GIT warn you when you make a commit with trailing whitespace. This will be annoying, but if we aware of the problem we can learn how to deal with it.

Other approaches include using a pre-commit hook to cleanup offending files in a commit. This will require quite alot of googling and work.

Base and Master Branches

Most Git apps have a master branch. When you set up a new application from FBRP your master branch will be tied to FBRP. This is not desirable. So instead we create a 'base' branch for fbrp

gch -b base

Now we modify .git/config.

[remote "fbrp"]
    url = git://github.com/diabolo/fbrp.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "base"]
    remote = fbrp
    merge = master

What this does is tie the base branch in our new application to the master branch of FBRP. Now when FBRP is update we can pull directly into the base branch

gch base
git pull

After that we can merge back into the master branch doing a rebase

gch master
git rebase base

Setting up local remote

We can clone our new project and put it on little-un. In the following our new project is 'tc4'

git clone --bare tc4 tc4.git
scp -r tc4.git deploy@little-un:/srv/git

Now we remote into little-un and change permissions

sshlun
sudo chown -R git:git /srv/git/tc4.git/

Finally we go back to our dev box and clone a new project

mv tc4 tc4.old
git clone git@little-un:/srv/git/tc4.git

If we do a

gb -a

We get

* master
origin/HEAD
origin/base
origin/master

If we wish to get updates from fbrp to our new clone we have to create a local base branch and update our .git/config as above

gch -b base

modify .git/config by adding

[remote "fbrp"]
    url = git://github.com/diabolo/fbrp.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "base"]
    remote = fbrp
    merge = master

Now we should have

Branch | Push          | Pull 
------ | ------------- | ------
Base   | no            | yes (little-un) 
Master | yes (github)  | yes (little-un)

Initial Application Steps

• database.yml
• update session key in environment.rb
• update application name and repo location in deploy.rb
• create local database tables

Then migrate and run

rake spec
rake features

Pre-Requisites

• rails project
• using git git init .

Installation

Plugins go in vendor/plugins

git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec
git submodule add git://github.com/dchelimsky/rspec-rails.git vendor/plugins/rspec-rails

Then run

script/generate rspec

Note: You need to run the following two commands (or at least the last one) every time you clone this repo.

git submodule init
git submodule update

I have two users on my server

1. Deploy - who is responsible for deploying applications
2. Git - who is responsible for Git things

Using capistrano my deploy user has to get the latest src from the git user. Using ssh to do this kept giving me ssh errors.

In the end I had to create a key pair for deploy and put the public key in the git users authorized keys file. Because I could not log in as the git user I had to do this as root.

mv /home/deploy/.ssh/id-rsa.pub /home/git/.ssh/deploy.pub

then backup the authorized keys file and then change permissions so I can write to it.

cd /home/git/.ssh
cp authorized-keys authorized-keys.old
chmod 777 authorized-keys   # give all access
cat deploy.pub >> authorized keys # must use double arrow or will overwrite not append!!
chmod 600 authorized-keys # has to have minimal permissions or ssh will complain

Warning

Instructions above are very rough and probably not totally accurate be careful

Update

May well have been able to do this using

set :ssh_options, { :forward_agent => true }

Which forwards ssh keys from the local machine through the web-server to the git-server

With an existing new project (we will use 'tc') which is already under git do the following in the directory above the project

• ensure the project has no pending work. git status should show nothing outstanding
• move to folder above the project

• clone the project (in this case we will clone tc to make tc.git)

  git clone --bare tc/.git tc.git
  

• move the clone to the git server

  scp -r tc.git deploy@little-un:/srv/git/
  

• I have to do this as the deploy user (my Git user does not have sufficient rights) so I need to ssh to the server cd to /srv/git and change ownership

  sshlun
  little-un > cd /srv/git/
  little-un > sudo chown -R git:git tc.git
  

Now we dump the local repo and clone a new one from the remote one.

cd ..
mv tc tc.old
git clone git@little-un:/srv/git/tc.git

Currently git doesn't support repositories within repositories. This becomes a problem when we are working with Rails projects that use plugins linked externally. If you are just using subversion you'd generally manage plugins using svn:externals or Piston if you're wise. There is a tool called Giston, which addresses that problem in the Git world. Unfortunately I couldn't get that to work.

Using symlinks

The solution I'm using combines two solutions from

• new bamboo
• sanity, inc

The technique is to use symlinks from your projects vendor library to seperate Git repositories of Rails and the plugins you are using. Sanity, Inc provides a GIT repository of the Rails SVN repository at git://git.sanityinc.com/rails.git. Creating this probably took days, but now its done, its very small (9MB) and quick to download.

Now you can link from your project to this repository.

cd myrailsproj/vendor 
ln -s pathToSanityRailsGit rails

The fact that you can change which version of rails you are working against in just a few seconds is very cool e.g.

# In Git Repository for Rails
git checkout -b 2-0-stable origin/2-0-stable

will change you to stable Rails2. Use git-branch -a to see whats available.