I’ve had problems with eclipse freezing in an annoying way. It seems this is mainly due to the stop the world garbage collector, as I’ve found the following settings work well in improving the situation.

Read Post »

I don’t use vim all the time, but it’s my fall back editor for when ever my GUI editor du jour is found lacking. Here is the .vimrc file I use in both MacVim on Mac OS X and gvim on Windows.

Your corporate overlords want you to use Cleacase?  Your team want to use Subversion (SVN)?  Then you need my handy Clearcase to Subversion migration script.  This script is based on Clearcase UCM, but can easily be adapted to run on base clearcase.  We ran it from inside our builder server, and set the build script to run 5 mins after a checkin to SVN.

@echo off
setlocal
REM DRYRUN=-preview
set PVOB=\PROJ
set CC_VIEW=Z:
set SVN_BASE=http://hostnname/repo/svn/trunk

echo Reading current head revision
svn info %SVN_BASE% | grep "Last Changed Rev" >curver.txt

echo Parsing latest SVN version
FOR /F "tokens=4" %%i in (curver.txt) do set REV=%%i

set EXPORT_DIR=export-%REV%
set EXPORT_DIR_FULL=%CD%\%EXPORT_DIR%
set ORIG_DIR=%CD%
set DIFF_FILE=%CD%\diff-report.txt

echo Current dir is      : %CD%
echo Export dir is       : %EXPORT_DIR%
echo Export dir full is  : %EXPORT_DIR_FULL%

echo Exporting SVN revision %REV% to %EXPORT_DIR%
svn export --force -r %REV%  %SVN_BASE% %EXPORT_DIR%

rem check that the export worked ok, and abort is there were problems
if %ERRORLEVEL% neq 0 goto EXPORTFAILED

echo Making clearcase activity
cd /d %CC_VIEW%\path\src\
cleartool mkact -in stream:STREAM@\PROJ migrate_svn_%REV%@%PVOB%
cleartool setact migrate_svn_%REV%

echo Executing clearfsimport
clearfsimport -recurse -rmname -nsetevent %DRYRUN% %EXPORT_DIR_FULL%\*
%CC_VIEW%\TfSrc\J_Was\

rem check that the export worked ok, and abort is there were problems
if %ERRORLEVEL% neq 0 goto IMPORTFAILED

echo Checking for differences
diff -r %CC_VIEW%\TfSrc\J_Was\ %EXPORT_DIR_FULL% >%DIFF_FILE%

echo Creating ClearCase baseline
call C:/apps/Python24/python.exe baseline.py

echo Cleaning up
rmdir /s/q %EXPORT_DIR_FULL%

echo Migration Finished
goto END

:EXPORTFAILED
echo Migration Failed, problem with svn export
goto END

:IMPORTFAILED
echo Migration Failed, problem with clearfsimport
goto END

:END
endlocal

The echo at the end is important, as you can use it to detect errors. We used Luntbuild as a build server, but cruise control would work fine too, and ran the script from within the build server. We set Lunbuild up to look for ‘Migration Finished’, if it didn’t get output, then I’d get an email informing me of the problem. Failures we usually due to the ‘evil twin‘ trigger in ClearCase rejecting the commit. If this happened I had to fix it up manually before re-runnning the script.

Recently, on a project, I’ve been learning about Lean, Real Options and Kanban.  On the project we used these principles to guide how we architected our release process so we could be ready to release at any time (mostly) without branching.  We did it mainly by being able to use config to turn features on and off, and aiming for backwards compatibliy.   That way if you deploy a new version, but don’t turn on the new features, it works exactly like the old version.  This means multiple features can be developed in parallel, and a release can be made when any one of them is ready.

Chris Matts my old project manager started a thread on the kanbandev mailing list asking if other people used similar techniques:

One of the most powerful techniques I have used over the last three years is latent code patterns. The project I just left made every feature configurable. This meant that we never had the situation where a fix / feature had to wait for another feature in testing. We focused on fast and effective regression testing. Despite frequent diva releases we only ever had a single branch and had no code merging issues as a result.

Is anyone else using latent code patterns? I would like to hear how others do it as the best lnnovation comes from practitioners with a problem.

The other issue that lcp raise is the wip limit around testing. Thoughts?

I’m not scared of SCM branches and merging, I can merge with the best of them.  Inspired by Chris’s demand to defer commitments, I made a conscious decision to avoid all branching unless absolutely necessary.  At the beginning it was an experiment, encouraged by the cost of branching.  The cost of merging, resolving conflicts, tracking which bugs are fixed where etc all add up.  That time and energy can be better spent finding a solution whereby we can make decisions as late as possible.  We wanted to able able to sense ambiguity in the requirements and code it up both ways, make it easy to change our minds.  Reduce the cost of change.

From the responses it seems some of the ideas we’ve been using are in use by others.  Some mentioned using dependency injection, but it’s not clear that others were affecting dependency injection at runtime like we are.  Others mentioned the command pattern, and it did indeed sound similar to our approach.

The thread was also summaried in the InfoQ post Enabling the Last Responsible Moment in Deployment which I think is a fairly good summary.

Next I will cover the techniques we use in more detail.

This is my new technically-themed blog.  I intend to write a post posts occasionally about my technical interests in software, programming and related bits.

I’m hoping to put together some posts about setting up a development environment for a small team using SVN, Trac, Apache, ActiveDirectory, Maven and CruiseControl.  I might do some posts on XML, both thery and practice.  And then whatever subjects take my fancy.

So do check back soon.  In fact why not subscribe to the blog feed and let my blog posts come to you.