You’re Not Using Source Control? Read This!
Last week I wrote an email to a client who hasn’t yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You’re not using source control? Read This! (PDF, no registration needed).
The document goes on to talk about the available tools (git, Hg, SVN) and give a sales pitch for _why_ source control has benefits for an organisation. There are also some action points to follow to implement source control if you haven’t already taken the leap, which I hope will help anyone looking to take that step – it’s kind of awkward in this day and age to admit that your organisation doesn’t have source control, but however this situation arose, hopefully this document wraps up my thoughts on how to find a good way out!
I’ve put a link to the document under the “publications” section on this blog as well, in case you need to refer to it again later and it gets lost in the torrent of blog posts around here.
I wouldn’t really recommend SVN for any team, I’d go with hg for a team of beginners, and git for a team of experienced developers. A team that have never used any version control before would benefit more from hg, and the added bonus of easy merges, cost-free branches, and that they don’t have to be online to use the system. They also don’t have to unlearn anything, unlike someone who switches from a centralized to a non-centralized VCS.
It’s a great read, I think the sales pitch is very nice. I have a similar blog post where I wrote about how I introduced hg to a small dev team, if anyone’s interested: http://ihaveabackup.net/2011/12/04/introducing-mercurial-to-a-small-development-team/
I would agree with this: go straight to a distributed version control system if you have never used any version control before. The SAAS version control services make it very easy to use these days, even given the complexity of the internal workings. A non-distributed version control system would be more suitable for a team of one, where there is no negotiation needed between team members about who can commit and when.
This article describes practical workflow model, and shows how it works visually in a way that none of the help pages does. It is well worth all team members having a read before first using git:
http://nvie.com/posts/a-successful-git-branching-model/
I have the poster printed out and stuck over my desk – it is very handy. I’ve used distributed control system for over ten years now – bitkeeper, monotone, git – and never looked back.
Great Whitepaper, very usefull! :)
I agree with Norbert, nowadays recommending SVN is a no-no. And Windows is not a disadvantage, as on our web-agency (Ponto Criativo) we recommend for our Windows Developers the great “tortoisegit”, a port from Tortoise SVN for GIT, and works like a charm, simply perfect…
http://code.google.com/p/tortoisegit/
lol this article would be very worthy in my company! It as a whole has Subversion, but it’s used only as a “stronger file sharing”. There’s no source version control – indeed, they force us to save whole source inside a zip!! – and they use it just to centrally save files.
And in my team not even that they do, it’s very often they forget to commit some file and lose it!
It’s sad that our Subversion is still 1.4… and when I asked to upgrade they didn’t accept saying that it was never upgraded and nobody uses it… pretending that I’m just troubling wanting to use it “all the time”!!