To Version Control or Not?
Posted in Tech/Development, Web strategy on: Monday, August 18, 2008 by
Version control can seem like a very daunting thing to incorporate into your work flow, but once it’s there you can be left wondering how you ever lived without it. Paul Stanton gives his thoughts and experiences on the subject.
This post has stemmed from an e-mail by Simon Hamp whom has just started working for a PHP development team and has been given the task of assessing their current systems. Simon writes:
I wanted a professional opinion on a proposal I have made to move from file-based version control (i.e. manual folder management) to full-blown source code management.
Is it worth making the change from an existing system and move to something like Subversion for a team of our size, considering that this would change the processes for those who have been here the longest quite considerably?
Version control is one of those things that you already know you should be using, and if you’re like me, have promised yourself for a while that you’ll get round to learning and integrating into your own workflow. Chances are that one day, disaster will strike and you’ll realise why it’s so important.
I’m going to be honest with you here, I can’t profess to be an expert in version control. I’ve been playing around with it, and the team I work with are very close to making it a mandatory part of our design and development workflow, but I hope i can provide some form of assistance in your decision to adopt a version control system, and maybe convince myself in the process.
That being said, I don’t think there even is a decision to be made. You – need – version control. There’s no real question about it. The biggest challenge we face is integrating this into our existing workflows.
Let me take a step back, and explain what version control is for anyone unfamiliar with the concept.
Version Control Systems (VCS) (also known as Revision Control, Source Control or Code Management) is a way of managing multiple versions of the same information, which is most likely – in this case – the source code of your website.
In the simplest terms, VCS allows you to keep track of the development of your source code, keeping track of the changes you make as you go along with all the changes being stored in a repository. You may already use a crude method of version control yourself, naming files such as index1, index2 etc. VCS systems keep track of all these changes, and let you revert to any previous version if the need arises.
The real benefit of VCS comes when you have more than one person working on the same file. Instead of you overwriting each other’s changes, or attempting to manually merge the changes from one developer with the changes of another, the VCS can take care of all this for you, creating branches for each developer to work on which allows multiple developers to work on the same file simultaneously, then merging the changes into a single version, highlighting any conflicts or problems that may arise.
There’s plenty of more detailed descriptions of VCS systems online if you’d like to learn more (Wikipedia might be a good place to start), so I’ll save diving too deep into the rabbit hole for now, I’m sure that if you’d really like to learn more, Paul can work it into future shows. For now, I’ll return to our case in point; “Is it worth making the change from an existing system and move to something like Subversion for a team of our size”.
I work in a team of 11, with 2 other designers and 3 other developers, and we ran into issues recently with a site that needed some last minute changes made. I was asked to do some markup modifications and CSS changes which required me to modify multiple files. This project wasn’t in a VCS system, so I was given a copy of the files on a flash drive. I made my changes, re-saved the files to the flash drive and handed back to the designer. In the mean-time, the designer had made other changes to the files, and needed to merge my changes with her own manually by copying and pasting from my copies of the files. To further complicate matters, the developer then needed to take these files and integrate the markup and CSS into their .NET templates.
I don’t need to tell you that this was an absolute nightmare, at one point we were managing 5 local copies as well as 2 remote copies (one on the dev server, and one on the live server) To be fair I’m not sure if the team has ever hit a problem such as this before, with multiple people working simultaneously on a project and unfortunately we don’t have VCS as a mandatory part of our workflow as yet, but after this experience, I’m sure it won’t take long.
If we did have VCS, I could have checked out the necessary files, made my changes, and checked them in, the other designer could have checked out the same files and made her changes simultaneously, and also checked them in when she’d finished. Then we could have simply merged these together into one, any conflicts would have been highlighted for us to easily rectify. The developer, when ready, could easily deploy these from the dev server to the live one with a couple of commands.
There will be issues with integrating this into your own processes, especially with people who have their own tried and tested systems, but personally I think you really have to put your foot down here. VCS should be a mandatory part of your workflow, especially as your team grows and there are more people involved with projects.
If possible, I’d recommend arranging training sessions on whichever VCS you choose to adopt, you should only need a day, or even a half day to go through the basics of using a VCS for your dev team, I’d even wager (or should that be “hope”) that those who have been professional developers for some time will already have experience of one form of VCS or another and shouldn’t be resistant to using one.
My last point would be to explore the various VCS systems on offer. The main 3 that come to mind when writing this article are Subversion, GIT and Mercurial.
Subversion (SVN) is the system that most listeners will have probably heard of. SVN is a centralised VCS system which centers around a single repository. Subversion is a well known, and generally well supported tool with a wide range of user interface tools available such as such as IDE extensions for most popular IDE’s and Windows Explorer shell extensions like TortoiseSVN. There’s also native Windows and Mac GUI tools available to make the normal command line interface a bit easier to digest.
GIT and Mercurial are slightly different in that they’re Distributed Version Control Systems (or DVCS for short). While Subversion manages a single repository, a DVCS system like GIT has multiple repositories. The best way I can explain is that imagine if my team was working on a project, and we had a repository on our dev server, I can then clone that whole repository to my laptop, and take it away to work on at home, on the train, or at the top of a mountain if I so wished. With a centralised VCS like subversion, you really need access to that central repository to commit your changes, with a distributed system, all your developers can mainta
in their own local copies of the repository, commiting changes to the master repository when needed.
GIT is actually the system I’m getting to grips with at the moment, the branching, tagging and merge tools are more stable than the ones within Subversion. Please note that I’m not trying to bait anyone here, and I don’t want to get into a flame war about which VCS is better than the other. GIT’s distributed nature makes more sense to me personally, and allows me to manage my branch without network access if needs be, and in the event that our development web server with the master repository blows up, each developer has a copy of the repo in some form, and there is a good chance that the whole codebase can be rebuilt easily.
So I hope this persuades you into adopting some form of version control, but if you really ask yourself, you already know that you need to use it, and to return to Simon’s original question, I bet your developers already know they should be using it, they just need a little encouragement to integrate version control into their processes, the benefits far, far outweigh the disadvantages.
By Paul Stanton
23 Comments
Comments are for the discussion of this post. If you have other questions / comments then post them to the forum or send me an email
Wouldn’t using Dreamweaver’s Check In/Check Out solve your problem?
Do you really need full version control? I guess this depends on the size of your project and the number of people working on it.
Yep, go for the version control, no doubt about it.
If users of this system are worried about using something based on the “simpleness” of it, I will suggest this order:
1 – Subversion
2 – Mercurial
3 – Git
I’m a Mercurial guy, but reading about designers using this maybe having something simpler would be better.
The strong point of Subversion is the availability of good graphical tools for it (maybe a plus for the not_quite_powerusers)
PS: Also try Mercurial, it doesn’t have as much marketing as Git but you won’t spend lots of time getting in grips with it ;)
I have only been a serious web developer for about 2 years now and there have been quite a few habits I’ve been coaxed into by my brother (Charles Nutter of JRuby) and the Rails community at large, and the big one was version control. I have two left hands when it comes to UNIX and that’s the big reason why I avoided setting up subversion for my projects, but I finally decided to get it done about 6 months ago and looking back on it I can’t believe I made it that far without it.
Not only has it already saved my butt big time on a few time-sensitive projects, but it has made my deployments and updates an absolute breeze. I’m going to jump on the GIT bandwagon soon too and from what I hear the learning curve is taller than that of SVN but the functionality better.
I have also had countless hours saved by version control. It can be so handy when you release you need some code that you removed a few days back. It’s a simple case of just opening the history and finding what you need.
If getting something like SVN running yourself puts you off, why not consider one of the many hosted options (many with free plans). For example, http://beanstalkapp.com/
Subversion is great, as Paul says you take a copy of repository files locally and can work on them to your heart’s content on- or off-line. When you’re done you commit your changes, and Subversion merges any changes made by other people.
You can create “branches” in the repository which effectively creates multiple copies of the files, which can be worked on separately and merged together later if required.
I’d recommend TortoiseSVN as an easy to use Windows client for Subversion, if your favourite editor doesn’t have SVN support built-in.
Thanks for the answer Paul. I appreciate your time spent on this topic. And thanks for all the comments guys (and gals).
I’m convinced that version control is definitley the road to take. Sadly I’m not the one who makes the decisions, just the proposals. So I have to leave this one to the bureaucracy.
Thanks for your input!
Long live boagworld!
Sorry… credit to Ryan! couldn’t see your name… it’s a very light grey!
@SnakeOil Does a cake really need icing?
VCS isn’t just for “big sites” or teams, it’s indispensable in and of itself. Being able to go back through time in your code, finding which revisions caused (at the time undetected) bugs is a blessing. Being able to scan through commit comments is always handy. Tying this into an issue tracker just makes life a dream.
The main reason people don’t implement it is because of the fear factor that it takes too much time, or is hard to get it going. By and large this is a fallacy.
I am a freelance web & graphic designer I work by myself I have use SVN before in a company I worked at but would I really benefit from using Version Control?
Sorry if I sound naive.
Cheers,
Danny
I’d been thinking about version control for ages, but eventually the other day I decided to bite the bullet and take a proper look at the options.
I went with TortoiseSVN and I have to say – it’s easy, and painless, and I wish I’d done it sooner.
TortoiseSVN has a fantastic help guide that does a very good job of explaining the concepts behind SVN and why it’s a good thing. I’d recommend setting aside two hours of your day to read through the help guide, install the software and set up a test repository for one of your projects. That’s all it’ll take and you’ll never look back.
You’ll be amazed how simple it actually is.
@Simon Hamp: You had it right the first time. Paul Stanton wrote this article. I just published it. :-) Credit goes to him.
I’m not even working professionally as a web developer but I’ve started to use SVN recently (and I’m only in a team of one – me!). I’ve used config. control software for a number of years at work now (for software development) and I think that it’s a big mistake to ‘not’ use it. I think a VCS is essential whether you’re coding at the server end or writing HTML/CSS/JavaScript.
I’d echo the comments of others here: TortoiseSVN really is the bees-knees. It definitely makes dealing with version control so much easier, especially if you’re a designer who isn’t used to arcane command-line kung-fu. Plus it integrates really nicely with apps like E Text Editor providing a seamless experience. I am actually very comfortable with the command-line, and I still prefer Tortoise.
I tried Git a while back and really grew to love it, but I’ve switched back to SVN for now because I ended up missing TortoiseSVN so much. Once Git has a UI as useful as Tortoise, then I’m going to switch permanently.
@Danny Absolutely! You must have had moments when you accidentally overwritten something you needed? Or rewrote some code only to want to go back to the original? It’s not just for managing code for multiple users, it’s also a form of backup.
I’m a front-end guy without a much experience with source control and I find Git a pleasure to use with the help of GitHub (http://www.github.com).
Thanks Lee I will have to implement it.
Anyone know of a good tutorial or starting point for setting up SVN on a Mac?
Cheers,
Danny
Source control really is a must: I’ve used subversion to manage a one-man project and it definitely was NOT overkill.
I’m a bit confused by your description of DVCS – I’m sure there must be more to it. If the only benefits are the ones you describe, I don’t see a difference between that and just checking out the entire repository (which is quite a common case). Is there some aspect of merging between the checked-out repositories that you’ve omitted?
There is no reason not to use version control on even the smallest of projects – it’s as useful for one man bands as it is for large projects with hundreds of people on a team.
Why would you want to use a DVCS with decent branching/merging support on a web design project? Well, here’s a scenario: you have two developers and three designers. The designers are working on creating CSS and graphics for the site, and are working away on their own branch. Meanwhile, the developers are working on the data model of the site. The devs can swap changes between themselves all day, while the designers do likewise. When the developers are happy they have gotten the code ready for the designers, they pull the branches back together, merge and push that to the designers.
As for why you should use a DVCS like Git rather than a centralised system like SVN – simple. You can check out from an SVN repo and work offline, but you can’t commit until you are connected again. Commits take much longer: as it’s got to transmit your code to the server. This means that any person working on the code does not have the ability to commit little changes, leaving many, many hundreds of changes lying in the working directory. Git users, on the other hand, can commit as much as they like. I’ll often commit shockingly small amounts of code – because committing a change does not mean that I am sharing it with the team (which, as an open source developer, for me means anybody), but can come back and roll back my changes before pushing them out to others.
I’d strongly recommend Git. It really is liberating to have a version control system that doesn’t require a server – starting to use version control is as simple as creating a directory and running “git init”. I now use version control for the tiniest of jobs. Git user interfaces are getting better: TextMate on the Mac now has a nice interface for Git, and there is an excellent project called GitNub which is developing a similarly pretty OS X interface. There is also “git-svn” which allows you to use Git to locally work on Subversion repositories – useful if you have switched to Git but find yourself working on a project still done in Subversion.
One other things that is worth noting about Git: look at commit hooks. This is a feature in Git which can lead to some serious cool. You can basically set things that run before or after a commit is made. What could you do with this? Have it so that an automatic e-mail is sent to the team (or anyone else for that matter) upon commit. Or perhaps have it so that it checks all HTML in the repository with an (X)HTML validator to make sure that no non-validating code gets checked in. Git hooks are awesome and really useful.
In a previous job, I helped set up and institute Subversion. After using it for just a week I could not believe how I had coded without it before. Usually, only one person worked on a job, but having that code history was very reassuring. When we did share projects, being able to merge two versions of the same file was just killer.
TortoiseSVN does absolutely rock. It’s also a good idea, if you have a few developers, to install a web-based repository viewer (like WebSVN), which makes browsing your projects history a breeze.
I’ve also used Microsoft SourceSafe, which flat out sucks. Stay away.
Thanks everyone for adding your opinions, some awesome comments here :) I might have to do a follow up at some point, as I mentioned, We’ll hopefully be making a push soon for GIT to be a mandatory part of our workflow (yay!)
Git for designers http://hoth.entp.com/output/git_for_designers.html
I can only agree on version control being essential. It has really nothing to do with how many persons access the files – I use version control at work with 50+ people on the same code (not at the same time of course but since we don’t have ‘code ownership’ you can find anybody working anywhere).
But I use it also for all my private stuff.
Ever thought “damn, I know there was some version that solved this better than my current”, or “why the hell did I do *that*?”
There it is: every saved version in the version control has a descriptive message attached, so you’ll never click through file1 to file25 to find what you look for.
And this history is never lost.
All vcs have an intelligent way of saving this history (saving only the difference between versions or doing other stuff), so you usually don’t need to worry about disk space too much either.
I wouldn’t recommend git to any beginner until the git developers got there user interfaces right (I use it at work). It fails to follow the one strictest rule I have regarding vcs: “Never ever destroy my data”. But git is definitely the one vcs with the largest feature set. If you really want to go for git, then I would advice to have somebody at hand who already knows git very well.
Neither SVN nor Mercurial requires you to set up a server. The choice between SVN or Mercurial is then probably one of taste, a choice between “centralized” and “distributed”. (Personally I like the distributed way).