I'm assuming you mean apply it to the branch.
Sorry. That's what I meant.
As for the revision, http://issues.apache.org/jira/browse/TOMAHAWK-467?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel states 428204 I'm more than happy to learn how to do this myself rather than making you do it.
If you're using windows and tortoise svn its pretty easy. Find out all of the files affected by that revision. Then view the history with tortoise. Then select the revision and say you want to update changes from that revision only. I'm also sure there's even an easier way to do it from the command line - in fact I'm pretty sure I've done it before.
<RANT MODE> However, I think it's a backward approach to be making patches to a branch, and then porting them over at some later time to trunk. Branches should be static except when applying maintenance fixes, and those fixes should be merged over from trunk after being tested, not the other way around. As things stand, you get the worst of both worlds -- you have a branch that doesn't have the latest features combined with a trunk that doesn't have the latest bug fixes. In an ideal world, the timeframe for this would be small enough that maybe it wouldn't be a big deal, but we all know that releases take multiple days and often weeks in practice. </RANT MODE>
I disagree here. The branch is for code that is about to be released. If a major (and bug ridden) change is introduced after the branch it doesn't slip into the release. On the other hand, if its important to have it fixed on the core as well, you can merge down everything from the branch after you check in the fix. We just need to make a note (in the svn logs) of what revision was merged down so we can start from there when the branch is done (or the next merge is needed.) Ideally we're only sitting on the branch for a couple of weeks. Also ideally, there is no major bug like this that ends up slipping into the branch before it can be detected on the trunk. Sean
