Even the smallest amount of programming I do go in my repository, and I wouldn’t want it any other way – the luxury of being able to roll back and forth, branching, merging and suddenly sharing with other developers if the need arise is very nice!

One of the main issues though – especially when working in a team – is how often and how much to commit. During the past few years I’ve realized a few key points:

• You can never commit too often! (Given that:)
• You should never commit code that doesn’t compile!

Following these points is easy, important and gives you very high flexibility. I bend the  second rule a bit, and add the following:

• Branches are for experiments and long hard deviations, and
• Only trunk needs to be compileable at all times

This comes from the (well known) trunk/branches/tags-model which we established when we started using Subversion. We reserve trunk for the place from where we can always release a new version. Code in here should always be compile-ready – no exceptions to this rule at all!

Our branches are used for experimental development, new versions etc. and the compile-issues in here shouldn’t be to the annoyance of the other developers but generally no more than one day’s work should go in each commit (see the first rule)!

Needless to say I follow these rules very precisely all other projects, even the ones where I’m alone and working at night.

After reading this post my mind spent 5 seconds looping through all the data it has passively consumes over the last year – about formats and stuff. It was hard! For those of you who have seen the movie Butterfly Effect – I image it was like those loop backs…

Well… These days I do a large amount of programming and interaction with the Microsoft Office formats. This means that I do a LOT of COM interfacing from my C# code – and I generally hate it!

The only thing on my mind right now is the possibility of doing XML-only based input/output. And if I am lucky – I can add Open Office support in that process!