I got this tip from a member of our Java team, I’ll be honest about it, I dismissed it for a while because I couldn’t see how it would help and basically couldn’t get my head round it. That was until a few months ago, when I was creating “Kev’s Fabulous ANT Script” (More on that another time).

So what’s the main principal about patching, it means that you only commit production code to the main codebase but you’re able to backup in SVN (And thus available to all) your work in progress.

Once I spoke to the Java team more about who they were using SVN Patches the penny dropped and I wrote two simple ant tasks to perform the job for the ColdFusion development team in ColdFusion Builder. The first was to create the patch, and there are couple of things that caught me out (I wasn’t thinking straight other things on my mind is my excuse and I’m sticking to it) When I released the two tasks, I had to wait until someone had the real world need for it. At this point I was hit with my gotcha, new files didn’t get included in the patch file. The reason being you need to add them to SVN in your working copy (NOT COMMIT THEM) so that the SVN diff would pick them up. Once this is done the task is fairly straight forward for the team. It asks for the users SVN credentials, asks for the Initials of the developers working on the task (Will do another quick posting on this), the JIRA Number, Jira Summary and then what the patch includes. The ANT task then automatically adds any new files to the working copy SVN, then create a patch file and places it in a folder at the top of our project called _patches it then commits only this patch file into SVN and leaves everything else not committed.

What this means, is that being good Agile Developers you don’t commit non-production ready code to SVN, so by using a patch you can put the work your halfway through working on into SVN without it affecting the main codebase so it’s all backed up in case of the dreaded Hard Drive Failure.  The second benefit is that another member of the team can use the other ANT Task which basically consumes the patch, this just requires the JIRA Number and it will apply the patch to the users local Working Copy and thus can check another developers code  or indeed work together on the same issue on their machine before the actual code is committed to the codebase.
Also as we perform pair programming, if the work isn’t completed by the time a member of the team needs to leave, they can perform the patch and the other developer can crack on and again commit their patch back in before they leave for the day. This then means if the happen to win the lottery that night and never come back the team still have the code to hand and can continue to work on it.

So to implement this ANT task I used SVN ANT and a windows port of the GNU Patch, so SVN Diff will create a Patch Diff File for you and basically GNU Patch will apply it to your working copy. (Subversion 1.7 has a new command to do this for you but we’re still on 1.6 until all our tooling catches up)

So that’s it in a nutshell, the power of SVN patching will help keep your codebase production ready without losing any code should the worse happen.


4 Responses to How to use SVN Patches in your Agile Workflow

  1. AgoraC says:

    Why not just use a feature branch?

    I can answer partly answer this myself, because working with feature branches in svn in not always an easy task. If you need to update the code, you will need to merge the changes into the feature branch, you cannot just update (because the branch has lost track of where the code came from, for instance the trunk).

  2. Big Mad Kev says:

    Hi AgoraC, the reason we don’t want to have feature branches is they are a pain to support and maintain, we also have the golden Agile Rule that you only commit to SVN Code Base production ready code, this way the code is backed up and not lost and is automated.

    We also automate all our Database Releases from SVN and having feature branches work also make this a nightmare.

    Right now to deploy a production release I run one script and I get the SQL to upgrade the Database & a ZIP of the code to send to the deployment Team.

    IMHO Feature branches are evil, if they are not maintained, but as I say they don’t really fit into the main part of our development.

    Though saying that we do currently have a feature branch, but this is for a major re-factoring, but we ensure that lead dev merges down from trunk daily.

  3. Dave Turner says:

    I’m guessing there’s some reason you’re not using Git or Mercurial or their ilk for this? This is basically the main thing that a DCVS lets you do. When I first started at my current place I managed to get a guerrilla DCVS movement going and we were all happy committing and sharing non-production-ready code before pushing it to the official SVN repo. Once that was done it was pretty easy to convince management to ditch SVN altogether.

    • bigmadkev says:

      To be honest we’re finding this works for us right now and we have many more battles to fight in our goal of software craftsmanship I will be coming back to this one day but not in the near future. I have been thinking about using git svn locally to me (I’ll need to be comfortable with it first) again other battles to fight 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *