On one of my project, we have a SVN repo but since I prefer using Git, I’m using git-svn.

Git-svn has been great, it let me create my own local branches for each new set of features (that’s when I don’t forget to create a branch) and to commit all the changes back to svn.

The problem today happened after I did a simple git-svn rebase. I had some sort of error and my local repo looked like it got reverted to the head of the svn repo….

error: patch failed: trunk/app/models/view.rb:1
error: trunk/app/models/view.rb: patch does not apply
[blah blah]
sing index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...

I hadn’t committed to SVN for 24 hours and had a lot of work that was just checked in locally… You can imagine the panic. Rob started digging in the .git repo to finally find the hash representing the latest delta before the rebase. With the help of the #caboose guys, I did a simple

git reset --hard hash-name

Which restore my repo to the pre SVN commit state. Awesome… however I still had issues to commit my stuff. After a little while I as able to commit again, worked a bit more and tried to commit again…. same error

But this time I noticed I could simply do

git rebase --abort

to restore the original branch.an

But I still couldn’t commit properly… until I discovered that I just needed to fix the conflicts manually using

git-mergetool

git-mergetool uses whichever merge tool available: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff filemerge

I fixed my conflicts in no time, then did a

git rebase --continue

and finally

git-svn dcommit

Looking back, I wish I knew how to properly deal with conflicts when using git-svn, I wasted a bit of my precious time hopefully this post will help you.

p.s: here is an interesting use of Sake to handle git-svn

Since then, they also released

but I’ll keep that for another post.

I’ve been using Lighthouse for a little while and I have to admit that I was a bit confused at first. I’d like to share with you why I’m really pleased with Lighthouse and why I think you should consider using it too.

You have probably figured out, I’m a little biased. So let me give you my conclusions right away.

• Lighthouse is simple and efficient.
• Lighthouse is more than a bug tracker, it’s also a project management application.
• Lighthouse helps you communicating better with you clients.
• Lighthouse doesn’t lack any features I used in trac.
• Lighthouse helps you keeping it simple.
• Lighthouse has a nice UI.
• Lighthouse is really cheap (it’s not free but almost).

The 2 things that threw me off when I switched from trac to Lighthouse were:

• the lack of integration with Subversion
• the weird way of organizing tickets

SVN integration:

So, no Lighthouse doesn’t have a repository browser, you would need to use warehouse, trac, retrospectiva or another tool. I personally don’t think there’s a real need for such a tool, but others might disagree. However, Lighthouse has a subversion beacon(Beacons are services that can be used to interact with Lighthouse). You can really easily install the beacon on your subversion server and committing code will leave a comment in your ticket, add a tag, change the status etc.. check this video to see how it works. That’s something I never did with Trac and I spent a lot of time editing tickets to mention the changesets related to issue related in the ticket.

SVN integration conclusion: better than expected

Organizing tickets:

I like having my tickets well organized. When i switched to Lighhouse and I only had tags to organize my tickets, I felt a bit lost. Actually Lighthouse doesn’t only have tags, it also has milestones. My milestones are usually really simple: iteration 1, iteration 2, iteration 3, investor demo 1, iteration 4, beta etc… Milestones aren’t used to classify tickets but to give them a deadline. So I was still facing an issue since I wanted to organize and prioritize all my user story tickets, bug reports, feature requests etc… using tag is ‘ok’ but finding your tickets later on is a pain. I decided to do something I’ve been doing with trac for a while: adding a keyword in the topic line. For instance I would create a new ticket like that [bug] a user can’t use utf-8 characters in his name. It worked ok but I was still missing something. What I didn’t know was that Rick and Justin already thought about that and came up with a simple/cool solution: ticket bins. Basically, a ticket is just a pool of tickets sharing the same criteria. Creating a ticket bin is dead simple, search for tickets, save the search criteria. That’s it.

I could now start using my critical, essential, nonessential tags and create bins for them. What I love with bins is that they are not folders. A ticket can be inside many bins. For instance, my critical UI open bug will be in my current bugs bin, critical bugs bin and in my UI bin. (I don’t actually have a current bugs bin, but you see my point.)

User stories/bug reports/new features can all be entered via the same interface and you don’t have to worry since they can be easily sorted using your ticket bins.

Organizing tickets conclusion: awesome

What about Basecamp?

Basecamp is great but even DHH says it is not meant for managing development projects. It’s really meant for marketers and managers, in other words: my clients. But you still need a good way of tracking your code, Lighthouse isn’t perfect and I wish it had a better support of user stories but it’s by far the best tool I found so far. Regarding the lack of user stories/criteria support, maybe I’ll just write my own application and use their beacon interface to integrate both apps together…

This would work on Mac and Linux, sorry Windows users, you’ll have to slightly change the code below.

Live on the Edge

This is actually a bit tricky but it was very well covered by John Nunemaker in this post

To sum John’s post:

Create a normal rails project:

$ rails my_project
$ cd my_project

$ rake rails:freeze:edge

(or use checkout edge in the vendor folder)

$ cd ..
$ ruby my_project/vendor/rails/railties/bin/rails my_edgie_project

You now have have a real Edge project called myedgieproject. You can delete the my_project folder since we only used it to create our real edge project.

Now, we are not really done since we need to add the Edge files into our vendor folder so we don’t use our local rails gem.

I would refer to another post from John, that you can find there

$ mkdir ~/rails
$ cd ~/rails
$ svn co http://dev.rubyonrails.com/svn/rails/trunk .

We just created a rails folder called rails in our home folder and we checked out edge/trunk in it.
Now let’s go in our Rails app and setup a symlink to the trunk folder we just created.

$ cd ~/rails_projects/my_edgie_project
$ ln -s ~/rails/trunk vendor/rails

If you are using subversion, you can ignore the symlink so it doesn’t try to version it:

$ svn propset svn:ignore "rails" vendor/
$ svn commit -m "using new sweet rails setup as recommended by John Nunemaker"
$ svn up

Read more for advanced settings etc…

Install RSpec

Very straight forward, you just need to follow the documentation

$ cd ~/rails_projects/my_edgie_project
$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec
$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails

If you have TextMate, you might want to download the latest RSpec-X.Y.Z.tmbundle.tgz Bundle

Next thing you want to do is to install ZenTest

$ sudo gem install ZenTest

Make sure you install all the required packages.

If you are using Growl create a new file called .autotest in your home directory:

$mate ~./autotest

and add the following 2 lines to be warned when your specs/examples fail/pass

require 'autotest/redgreen'
require 'autotest/growl'

Now, lets go back to our project and create a model using the rspec scaffold (it uses scaffold_resource generator and create all the specs for you)

$ cd ~/rails_projects/my_edgie_project
$ ruby script/generate rspec_scaffold User first_name:string last_name:string :age:integer

Now, let’s start autotest (from zentest) so out code is tested in the background

$ autotest

There you go, really to modify your RSpec examples, make them fail, fix your code, examples should pass, refactor your code and start again