As I mentioned in an earlier post entitled “Three commands for Subversion enlightenment“, Subversion’s diff command is quite helpful in determining what local changes have been made.
The output of the diff command is somewhat verbose in that it literally compares the local version to what’s in Subversion. If you’ve made a lot of changes, the output can be overwhelming.
For instance, running the diff command (for a sandbox where only one file has changed) yields output like so:
aglover$ svn diff
Index: test.properties
===================================================================
--- test.properties (revision 126)
+++ test.properties (working copy)
@@ -1,5 +1,5 @@
#HSQL Database Engine
-#Tue Jun 03 10:49:01 EDT 2008
+#Thu Jun 12 17:04:23 EDT 2008
hsqldb.script_format=0
runtime.gc_interval=0
sql.enforce_strict_size=false
In truth, most of the time, I just want to know what has changed not necessarily how. Accordingly, you can pipe the output of diff to a grep-like utility searching for the line containing the word “Index:” like so:
%>svn diff | egrep "Index:"
In my case, I’m using egrep to search for a line of text containing the keyword. If, for some reason, the files you are changing actually contain that word, you might want to precede the phrase with a ^ (which matches the starting position of a line).
Consequently, using this pipe filter yields the following output:
aglover$ svn diff | egrep "Index:"
Index: test.properties
Now I can more easily understand what files have changed and update a repository appropriately.
Hudson is an open source CI server that is by far the easiest one to configure. Second to ease of use is Hudson’s impressive plug-in framework, which makes it easy to add features. For instance, Hudson has a plug-in for tracking FindBugs issues, PMD issues, and CheckStyle issues over time as well as code coverage. It also trends test results from JUnit, as well as build results and corresponding execution times. In spite of all these cool features, we had to find ways to get around some common issues we faced at work using Hudson.
This article describes a few real-life tips and tricks that we have found at work and will assist in configuring Hudson to work most effectively in your environment as well:
- Changing Hudson home directory
- OutOfMemoryError
- Securing Hudson
- Hudson Views
- Hudson and Groovy
- Spaces in directory names
- Browser to use
Changing Hudson home directory:
Hudson by default uses the $USER/.hudson directory as its home directory. If you want to change the home directory, set the HUDSON_HOME environment variable to some other location before startup. This is where Hudson maintains its configuration files and manages its jobs. If you are using a batch script to run Hudson, you can set the HUDSON_HOME there as well:
set HUDSON_HOME=c:\hudson\ci_jobs
OutOfMemoryError:
If you are seeing this error, set the maximum heap size as such:
java -Xmx512m -jar hudson.war If you are seeing the same error in spite of increasing the memory, report the issue to Hudson mailing list and take a look at the following link:
http://hudson.gotdns.com/wiki/display/HUDSON/I’m+getting+OutOfMemoryError
Securing Hudson:
Hudson does not perform any security check in its default mode. This means any person accessing the website can configure Hudson and jobs, and perform builds, and download all the files from within the workspace. Hudson can be configured to authenticate users and enforce access control. In the “Matrix-based security”, you can basically configure which users have what permissions in a big table. From the Hudson dashboard, click on Manage Hudson link on the left hand side which will take you to a page as shown below:

It is also a good idea to secure the Workspace as shown above. If not, once you have a successful build, anyone can download the source code from the Hudson Dashboard as such:

Hudson Views:
Rather than having a long list of all the Jobs, organize your jobs into different views; like Commit Builds, Nightly Builds and so on.
Hudson and Groovy:
The Groovy plug-in which can be found here is very useful. In our case, we are using it for many purposes. To name a few:
1. To unlock all the files which are locked by the SCM. Download a free utility called unlocker.exe and run the groovy script to unlock files as such:
new File("directory where files are getting locked").eachFileRecurse{file ->
def command = """"C:\\Program Files\\Unlocker\\Unlocker.exe" ${file} -s"""
def proc = command.execute()
proc.waitFor()
}

2. And also to change the file permissions on directories.
def ant = new AntBuilder()
ant.chmod(dir:"directory which needs the permission to be changed", perm:"ugo+rw", includes:"**/*.*")
println "changed permissions on dirs"
Troubleshoot Hudson:
If you want to troubleshoot Hudson, you can run arbitrary Groovy scripts. In order to do so go to the Hudson Dashboard and click on the Manage Hudson which brings up the screen as shown below:

Click on the Script Console, which will bring you another page where in you can run any Groovy script to troubleshoot Hudson.

Hudson Environment Variables:
You can easily incorporate the environment variables which are easily available within your build scripts as such:
<target name="retrieve-env-variables">
<property environment="env" />
<echo message="${env.BUILD_TAG}"/>
<echo message="${env.BUILD_NUMBER}"/>
<echo message="${env.BUILD_ID}"/>
</target>
Spaces in directory names:
If you use the default setting for Hudson-Home; it is in the “Documents and Setting” folder. This causes Ant build files to fail. Make sure you set your Hudson-Home to a directory without spaces.
Also, while creating a new Job in Hudson, it has been seen that Job names which have spaces cause trouble while running the Ant build scripts.
Use anything but IE:
Last but not the least, if you are using Internet Explorer as the default browser, switch to some other browser. I spent a day trying to fix the matrix based security and also trying to rearrange the Build Steps, and enter a Groovy Command. All worked seamlessly when I switched to Firefox.
Links to additional tips and tricks already posted here:
1. Retrieving error level
2. Versioning Hudson job cofigurations
3. Hudson’s so Groovy
4. Matrix based security and IE