DevOps, Git, Version Control Systems

How-to use Jenkins to keep your branches fresh


Although I prefer feature toggles over branching there can be instances that feature toggles are not practical. Think of a situation where you need to upgrade the underlying framework (or platform) of your application. Some examples from the Java world could be, newer JDKs, the latest Spring framework that contains breaking API changes, the new NetBeans platform that your desktop client is based on etc. etc.

In such situations when you have created a branch in your Git repo for development there is a risk that the master code base will diverge drastically from the branch. Therefore it is a good idea to keep your branch fresh by regularly merging ‘master changes’ into it. This not only saves you from having to resolve many conflicts when you perform a ‘big bang‘ merge, but it also ensures the functionality implemented in the master works in your branch more frequently.

Now you can do this manually by regularly merging master changes into your branch, but instead you can use Jenkins to easily automate the process. Since this can be scheduled to run frequently you will get faster feedback when a change in the master breaks your branch.

Here’s how you do it.

1: Setup a job that tracks both your master and dev branch under Source Code Management. Use the Additional Behaviours/Merge before build option to merge master changes into your branch.

jenkins_merge_branch1

In short, this would fetch master, merge into branch, build and (ideally) run all tests of your application.

2: Next use the Git publisher feature in the post build section to push your branch containing the merged changes to the remote Git repo.

jenkins_push_merge

You can perhaps schedule this job @hourly to ensure your branches stays fresh with master changes.

General, Subversion, Technology, Version Control Systems

Subversion Revert with Externals


Disclaimer: I know Git rocks, but people still use Subversion 🙂 !

Let’s say you have a Subversion checkout containing externals. Now you’ve made changes in many places within the folder structure and you want to get back to the original clean state.

So your typical approach would be to go to the top directory of the working copy and do a recursive revert using:

svn revert -R .

But unfortunately nothing happens! The reason is that the working copy is made up of sub folders containing externals and in order to revert them you need to go into each sub directory and then issue the svn revert command. This can be cumbersome if you have a working copy containing many subfolders corresponding to externals.

Well the solution is pretty simple if you have a bash shell (Windows users will require Cygwin or something similar)

for d in ./*/ ; do (cd "$d" && svn revert -R .); done

This little bash script will change (cd) into all sub folders using a loop and execute an svn revert within each ‘external’ folder recursively.

The solution was inspired by this thread on StackExchange.

Subversion, Version Control Systems

Subversion Revert All


Working with Subversion on Ubuntu requires that you get to know actual svn commands as opposed to using GUI tools such as TortoiseSVN in Windows.

Normally svn help gives you a list of available commands. But recently I needed to revert all my local changes in my code and couldn’t figure out the command (or more correctly the switch) required to do this operation.

Then I came across this blog which has a combination of awk and svn revert which looks pretty cool. But the simpler more efficient solution as given by the comments in the post is

svn revert -R .

Note the period after “-R”

This worked for me!