Mercurial in 5 minutes
What: Distributed Version Control System (Source Control)
Cost: Free (GPL2)
Care Factor: Low set-up and friction source control for personal or team work
Competition: git
Replaces: CVS, SVN, TFS
Known Aliases: Hg
Get
Mercurial - Core libraries and command line executables (included with the tools below)
TortiseHg – UI and Windows shell integration
HgSccPackage - Visual Studio Integration
Blame the hand holding TFS not TFS
Not having the confidence to do regular incremental releases begets branches in your source control which begets maintenance nightmares — @droyad
Amazingly my well thought out, articulate and detailed tweet above did not convey the message as clearly as I had intended. Who knew Twitter is a bad place for detailed and complex discussions? So to defend my position:
Thesis: Source Control problems are the result of the business process not the tool
VCS Choice
I’m going to use TFS and git as opposite ends of modern VCSs in this argument, but I would apply it to similar tools (eg Perforce and Hg respectively). I’m also going to make sweeping generalisations and realise that it doesn’t apply in all cases. I’m also only considering the VCS part of TFS </AssCovering>. I prefer Mercurial over TFS, as it’s a better tool, but often its not my choice.
Lost in Transmission
In a software project, there is a person (or if your unlucky a group) making the final decisions on what features to implement. Typically they are not actually the ones doing the work (which is a good thing). In Scrum terminology, this is the Product Owner (PO). Unless you are developing for the software industry they they are not a software person, rather a Domain Expert. They can reliably translate the worth of application feature X into business value. They communicate this to the development team by prioritising the backlog (or setting the schedule) based on the team’s estimates, cutting features where required.
First Steps Towards the Path
In my previous post I talked about the first step in implementing a difficult change is deciding that it need to be done and having a plan. In this post I’m going to cover strategies to get your desired feature/tool/process implemented, the How in your plan. Sometimes change is resisted from above (the controllers of the project) for various reasons, including time, money and a lack of understanding (“Those crazy code monkeys are screeching again”). Few people work in the perfect environment, this is for them.
Voted off the Island
Looking at this from the perspective of an employee, what’s going to be the cost to you personally? Do you care? Is it worth getting people offside, calling in favours or angering that manager? These are personal decisions that may need to be made if you want to drive the change. Sometimes it comes down to a “I can’t take it any more” decision, and one throws caution to the wind. Hopefully it doesn’t come to that, but if it does, write that email but don’t send for 24hrs.
Finding the Path
If you are lost in the woods, figuring out in which direction the path is, is the first step.
This post is spurred on by uglybugger’s blog post telling developers working on messy code to stop considering a complete re-write and fix the underlying problem. He cuts through the fear and says it’s not that hard. It really isn’t, except when it is.
Unless you are the one in charge of the resourcing and budget for a project, your going to hit a few walls unless that person is totally in agreement. Those walls could be minor or they could be huge, even insurmountable. The size, both length and width, of the project are going to play a part, along with how far you are off track.
So, getting to the point, you want to implement feature/process/practice X, and you need to convince the higher ups that it’s a really good idea. If you don’t have this problem, count yourself lucky, and make sure those below you don’t either. If you do, don’t get discouraged, with a bit of planning you can make things better.