Continuous integration strategy in Subversion

This is a great post by John Feminella I found in Stack Overflow:

As you note, one purpose of using a branch is to segregate specific code fluctuations from ticket-fixing and feature development away from the trunk. But once the feature or ticket is complete, you should merge it back. In Subversion, branches are better used to track sets of related features (like those for a release), not individual features. Otherwise you will quickly wind up with unmanageable numbers of branches.

Furthermore, why delay the integration at all? The longer you wait between releases, the higher the likelihood that your isolated change will conflict with another change made since then and/or produce further instability in your system once merged back.

My preferred strategy is to do something like this:

    [begin work on 0.4 branch]
       |
       |
       v              
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable".
         \       |          |        Contains all commits.
    ver   \   [merge from trunk]     Developers commit to trunk.
<-- 0.3    \     v          v
            +---(a)--------(c)-- <-- Branch is "stable".
                                     Contains selected commits from trunk.
                                     Know beforehand what's going onto branch.

Now, once you’re ready for release:

[trunk]
(*)---(*)---(*)----------------------------[development continues]--->


[0.4 branch]                        No further development on branch unless
(*)---(*)---(*)---[0.4-release]     spot fixes are needed. Then re-tag (0.4.1)
                          ^         and re-release.
                          |         
                          |
                       [make tag on branch; release from stable branch,
                        not unstable trunk]

I know you asked about the best way to coerce your continuous integration system to do this. But I would respectfully suggest that given that Hudson is recognized as a relatively capable CI system, the fact that you’re having a lot of trouble shoehorning your development model into it is a possible sign that it’s not a process that lends itself well to CI in the first place.

Our typical practice is to have two base builds per project: one against trunk and one against the current release branch. This way you know that:

  • Whatever is being updated is being integrated correctly (trunk)

  • Whatever your release target is, if you stopped working now you would still have a correct and working (just not fully featured) build.

Recognize routes in the Rails console

Depending on the Rails version:
r = Rails.application.routes
r = ActionController::Routing::Routes

Then:
>> r.recognize_path("/report/EH9/Payload/86188.html")
=> {:action=>"report", :diagram_name=>"Payload", :satellite_name=>"EH9", :controller=>"diagram"}

Seen in http://stackoverflow.com/questions/2778074/recognize-routes-in-rails-console-session