Posts Tagged → svn
Commit-policies
You use a version control system – of course you do! Personally I use Subversion (re-rolled from CVS) and no project is too small for version control imho. Both projects at work and at home go in a repository.
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.
Annoying merge
At work we use a Subversion server to store, branch and merge all our code. Generally this works out great! The life quality of the programming staff has risen quite a few nods after introducing this. Even as a single developer I can only recommend it – the posibility of branching and merging whilst hopping back and forth between different revisions is great! Simply great!
Anyway – one thing that constantly annoys me is the lack of code knowledge by the merge tool. This means that often when two developers has been editing the same file and lines there is a conflict that the merge tool can’t solve properly. Often when files are merged the result can’t compile! This means more management – which means an unhappy developer. Me!
To the best of my knowledge the merge tool could do a much better job if it simply knew what it was merging. A merge tool re-written specifically for C# code would in my oppinion do a much better job in these special cases. I’m not even going to start on the subject of designer generated GUI code merging. We do our very best to avoid this – it is always a source of great failure!
I’ll conclude this rant by noting that my irritation obviously hasn’t peaked yet. If this was the case I would’ve put some effort into a solution.
