Collaborate and Connect with Subversion
Issue № 262

Collaborate and Connect with Subversion

Consider this: You own a small web design and development shop. Maybe it’s just you and a couple of other people. Because of your size, you rely heavily on outside subcontractors. Subcontractors allow you to take on more projects, make more money, and scale your business carefully. Managing even a few contracted workers is challenging. At some point, you will hit a rough patch where subcontractors don’t deliver on time, don’t meet your quality standards, or—at worst—disappear and never complete the job. Proper vetting, solid references, and hands-on management can help. Technology can promote teamwork and keep projects in check. Enter Subversion.

Article Continues Below

Subversion connects and promotes collaboration#section2

Subversion (SVN) is a version control system that allows you to track and store code changes, collaborate, and share project files. It’s very easy. You write some code and “commit” it to your Subversion repository (the storage place for all of your project files). People on your team can grab those files, view your work, make changes, and then commit those changes to the SVN repository. Each commit is considered a “revision.” SVN tracks revisions and assigns them a number, so you can always roll back to a previous version of your work.

Visibility is a good thing#section3

Subversion also keeps everyone on your team involved in the project: commits and project changes become visible as they are made (see The Tools You Need, below). If you have solid subcontractors this just provides peace of mind, but if you have someone new it allows you to catch any misunderstandings, project issues, and coding mistakes before it’s time for the subcontractor to deliver the work.

Make it mandatory#section4

If a subcontractor wants to do business with your shop, make your workflow and toolset mandatory. Differing workflows can burden a small company—especially client services companies.

Some subcontractors may want to email .zip files of their work or may post it to a remote server for you to download and view. This is a nice arrangement but it puts your project assets and code out of your hands and into those of someone outside your organization. Effectively, you lose control of the project.  What’s the solution? Adopt SVN as your workflow. Besides the normal benefits of versioning and allowing multiple people to work on the same code at the same time, SVN keeps your subcontractors accountable and the project code and files for your clients in your control and possession.

As the subcontractor’s employer, you have every right to stipulate deliverables, the tools used, and how and when the work gets done. Your subcontractors will appreciate a solid workflow and know that you have your act together.

Are there exceptions to this rule?#section5

A process shouldn’t be enforced just because it’s the process. Depending on the subcontractor’s level of responsibility, you might decide you don’t need to include them in your Subversion workflow. You’ll know it when you see it.

Set expectations#section6

Everyone uses Subversion differently. Some people like to commit their project changes dozens of times per day. Others prefer to work through their projects and only commit their changes at the end of the day. Much depends on the type of project you’re working on and whether or not you’re working with others on the same code. I’ve found that the closer the project comes to completion, the more changes that take place over a short period of time. At that stage, I commit my changes to Subversion frequently.

Set expectations on how often you expect to see updates from your subcontractors. I recommend a minimum of once per day while they work on the project.

The good and the bad#section7

Certainly there must be more to this than just creating more administrative work for yourself, right? Of course. You gain the ability to measure the quality and quantity of work your subcontractors complete within a given amount of time. This instant visibility on productivity benefits you and your subcontractors: you don’t have to nag them to complete work while they’re integrated into your workflow.

Subcontractors may be concerned that this arrangement may lead to having their work used without compensation. If you always have their latest code, what stops you from taking it and not paying them? Subversion itself doesn’t create this situation, though—dishonesty can happen in any workflow arrangement. Make sure your contract clearly defines the deliverables and payment terms. There are plenty of resources online on how to create a contract and structure it so you’re protected. If you’re not currently using a contract for work you subcontract, get up, go sit in the corner, and think about what you’re doing.

The tools you need#section8

Refer to Mike West’s article I Wonder What This Button Does to get started and learn the basics of the version control system. In addition, O’Reilly’s Version Control with Subversion is an excellent (and free) resource. Be sure to read the chapter titled Fundamental Concepts for a good overview of the SVN workflow.

On its own, SVN can be daunting when attempting to manage multiple users with different permissions. For example, you probably want a subcontractor to have access to only a single project (the one she’s working on) and not to your entire repository. To facilitate simple SVN repository and user management, I recommend Warehouse, a web interface to Subversion, by Active Reload. Warehouse allows you to easily manage repositories, see changes and—most importantly—add users and set access permissions. User management in Subversion can be tedious—this abstraction layer makes it simple to add or remove users. It also provides RSS feeds of repository changes, so you and your team can see which project files are being worked on and any changes that took place. There are also hosted solutions, such as Beanstalk, that will host your SVN repository for you and include a web GUI for managing it.

While I strongly encourage people to first learn how to interface with SVN using the command line, you can also try out the new Mac OS X application Versions (currently in beta). It provides a GUI to most of the SVN commands.

Hooking into your current workflow#section9

Adding Subversion in to your current workflow doesn’t have to be a jarring event. With the right skills, you can hook SVN into your project management tools. SVN provides “hooks,” which are “repository events” where SVN will fire off any custom scripts you write. One example of this would be a script that would post a new message to 37Signals’ chat application Campfire every time you commit a change to your SVN repository—alerting your co-workers to changes you made. A Google search will reveal many other scripts written for different tools, including ways to integrate the project management tool Basecamp with SVN.

There are several different types of hooks but the most commonly used is the “post-commit” hook, which triggers scripts after a successful commit. Using SVN “hooks,” the ability to work SVN into your current workflow and toolset is nearly limitless.

Why are you still reading this?#section10

Subversion is not just a great way to version and control the code and assets for your projects but also an effective method of controlling and refining the interaction between you, your co-workers, and your subcontractors. Do yourself, your company and your subcontractors a favor; get your SVN workflow up and running today.

About the Author

Ryan Irelan

Ryan Irelan is the founder of Mijingo, where he has authored courses on Git, Craft CMS, ExpressionEngine CMS, Jekyll, website deployments, SVG, Grunt, Gulp, and more. He also does classroom teaching, technical consulting, and coaching. Previously, Ryan was vice president of technology at Happy Cog. Other than at Mijingo, you can find him at his personal site and on Twitter.

43 Reader Comments

  1. While the basic points about needing a version control system are sound, subversion itself is obsolete. The world has moved on to distributed version control systems like git (or perhaps mercurial).

    Certainly you wouldn’t start a new project using subversion – it’s only appropriate for legacy setups where making a switch to a modern setup needs to be delayed for some reason.

  2. Only a small part of the world has moved on to git, mostly Mac-based developers. The lack of a decent desktop client on Windows or requiring cygwin to use git at all is proof of that and means that there’s a larger barrier to entry for the the much larger development community that still works off Windows.

  3. Subversion certainly is not obsolete – it’s still the best free solution for Windows in terms of community and support.

    I’m also surprised that this article didn’t mention TortoiseSVN, an excellent Windows GUI for managing your files in Subversion. It integrates directly into Windows and lets you access your Subversion repository like any other Windows folder.

  4. I certainly never thought of using SVN to work with my freelance writing clients. This is just completely blowing my mind how I never saw to use it that way.

  5. While I would like for Git to be the mainstream way to collaborate on projects, SVN is still the standard.

    I am somewhat surprised by the number of great looking tools popping up for SVN ( “Versions”: & “Cornerstone”: ) since it does seem (from a Git user’s perspective) to be on the way out.

    One of the great things about Git is that you can use it with SVN repositories. I use Git every day with SVN projects and nobody else on my team has to know that I get all the benefits of Git while using the same old repository. Forking, branching, and merging are wonderful things.

  6. Once you start easing into the branchy workflow, you’ll never want to go back to Subversion. Subversion made branches cheap; Git makes merges cheap, and there is a world of difference there.

    I wouldn’t call Subversion obsolete, though. But I also wouldn’t call Git fringe.

  7. Another distributed version control system worth looking at is “Bazaar”: . It is very easy to install on windows (and other platforms of course). Its developers have paid a lot of attention to accommodating different “workflows”:, and I think it definitely succeeds at being more flexible than subversion, and probably the others too.

    I had used SVN previously, and recently evaluated several version control systems for my lab group, and ended up choosing Bazaar because I like its philosophy and I found it to be the easiest system to get up and running on our server.

  8. I never considered using GIT so far. Might be a good idea to take a closere look.

  9. Git on Windows doesn’t need cygwin alone anymore, it’s possible to use msysgit, with nice gui and terminal. It’s in beta but will be part off the official git soon.

    And it’s no problem to work with Git and Subversion over git-svn.

    I tried Mercurial and Bazaar, too. But git is my favourite. Subversion is complicated, inconvenient and insecure (files can easily get corrupt). With git all you need is a “git init” and your repo is working. Locally, no need for server configuration.

  10. I’ve got to say that I’m totally digging git.

    It took me a while to get into but once you’ve got the hang of it, it beats the pants off subversion.

  11. Do you ever wish you could search your entire SVN repository using just a web browser?

    “Atlassian”: create “FishEye”: for not only making your svn repository easily viewable, but also enables full text search across your entire repository.

    To make Code Review easier for distributed teams have a look at “Crucible”: as well. It is an extension to FishEye which allows Code Review to get done with a minimum of fuss.

  12. If you want to use version control like this, i.e. for a wide range of people with varying skill level, then you need an option which is user-friendly, file-friendly and windows-friendly.

    I personally use Bazaar for my own work. I was sold on it when I asked a colleague to install it, and on checking with her half an hour later she had it installed (on windows) and all her files checked in to a repository. She had never used version control before, and she had previously spent half a day unsuccessfully trying to install Subversion. Also, Bazaar has some really unique features like an attractive 1-page quick start card (which really is all you need to get started) and a website that actually makes you feel welcome.

    Subversion has a lot of problems. I’m not getting into the centralized/decentralized debate, but amongst other things Subversion wreaks havoc with bundle files by littering them with .svn directories everywhere. What Subversion does have, which in this scenario is invaluable, is a wide range of GUI tools. I hadn’t heard about Versions before, that looks very useful.

    As far as Git is concerned, it is a completely unrealistic option for non-programmers. The community is positively hostile to anyone who doesn’t immediately acknowledge the absolute superiority of Git, and that is never a healthy attitude.

    As a developer who uses and contributes to open source software, I have to be conversant with a wide range of version control tools. I use Subversion/SVK, Git and Mercurial on a weekly if not daily basis. I would like to see the GUI tool market and the version control hosting market move towards recognizing this reality, and be vcs-agnostic on the back end.

    For now, I have to admit that the GUI support makes Subversion the most realistic option for this sort of usage, with a user-friendly decentralized system like Bazaar a close second if your designers are willing to learn to use the command line.

    If you don’t find an option which works for everyone, you can always implement version control yourself and just check in the files which suppliers/designers send to you.

  13. Git crushes subversion if you’re really using something for version control and not just ‘sharing’. The ability to branch/fork/merge with git has been made so trivial that i actually do it now. Anyone ever stuck in subversion merge hell will testify to what a godsend this is. Seriously, if you’re just starting in to this, go for GIT. Check out github if you want an easy way to get a hosted repo online.

    If you want to use svn as the cloud repository, you can still use git locally to manage changesets (i recommend).

    SVN is a fantastic bit of software, don’t get me wrong. It has been quite a workhorse and made many an project easier to manage. However, it is time to pass the baton.

  14. Thanks to everyone for their comments so far.

    “Zac Davis”: Yes, writing workflows is an excellent example of other uses of SVN (and version control systems in general).

    In general, I’m wary of SVN vs. Git shootout, not only because that’s been done so many other places, but because it isn’t what the article is about. I’d be interested in hearing any experiences people have implementing version control in their small team of designers.

  15. I agree that introducing version control system is a great improvement for you work. I recently even made a step forward and let my client access the repository. He can see the changelog, the commit comments and the dates — I think this transparency helps to build trust, even when the diffs themselves are not understandable.

    As for which one you should use — hey, use whatever you are most comfortable with. Personally I love Mercurial, as it lets me to create and share a new project almost instantly — either by starting a temporary web server with ‘hg serve’, or by using the cgi application they ship. It also works well on windows and has TorrtoiseHG for those allergic both to WWW and Console. Oh and you don’t have to manage your repository — you just start a separate one for each project, move them around as whole directories, clone and merge when needed — much easier than trying to wrap your mind around branches and permissions and whatnot.

  16. It took me a few goes to get my head round version control, I work alone, building websites, and keeping track of all the different versions – local, staging and live servers, was getting tedious.

    I tried SVN a couple of times, and eventually settled on a workflow that makes sense, but only really adopted it properly when Versions came out for OS X. Funnily enough, shortly after Cornerstone was released and it’s much better. (one or two minor niggles).

    I’ve adopted a local repository and ftp’ing exported code at the moment, but ultimately will have a remote repository on my staging server, which will have a working copy locally for testing and on the staging server for client approval – this will allow other people to assist, by checking out from the staging server.

    It all makes sense now.

    I imagine tools like Versions and Cornerstone will make Subversion more widely used. When Git and Mercurial have the same easy GUI’s then they too will be on my list.

  17. While back end developers have been using version control for a long time now and may debate the pros and cons of the various version control systems, life in the trenches of front end web design and development (especially in smaller design studios and ad agencies with fast turnarounds) for the most part relies on much simpler and error prone methods of collaboration.

    Our studio has recently introduced SVN into our workflow and I can say that it has made a huge difference to the efficiency and an even bigger improvement in reduction of the amalgamation and release stress even in the smaller jobs.

    Hopefully this article will prompt more smaller development houses to adopt these excellent tools!

  18. Ryan, Thanks for the reference to Beanstalk. Our main goal when we started was to make the adoption process painless, this way people who might not use Subversion (or version control) could easily jump in without worrying about servers and installation.

    At the same time, even Subversion has a learning curve. Most of the effort starts with the Subversion client and understanding the workflow. So far, the response to our integration with Versions has been great. We’ll continue to reduce the barrier to entry so designers, writers, and anyone else can realize the benefits to version control.

  19. Thanks for the note on SvnX, Hadrien. I do know about it and that it is open source, however, in my use–and by some of the team at Airbag–we found it extremely difficult to use. In fact, that’s the reason I just had the people I work with learn the small handful of SVN commands on the CLI because it was actually easier than trying to navigate SvnX.

    There was no conspiracy to eliminate open source software, I just can’t recommend it as a application to use. Versions (and now Cornerstone) are much better choices on the Mac. However, I still recommend people first learn how to use SVN on the CLI. I feel it offers a greater understanding of how SVN works.

  20. I’m a ‘back-end’ developer and use SVN (having moved from the evil Microsoft VSS). Personally after getting my head around a few concepts I’ve never had any issues with it (not sure why there are lots of moans about merging problems – it’s really quite good). Choosing a version control system shouldn’t be a big beauty contest – if it works (and svn does a fine job) stop comparing it with all of the other shiny and new version control systems.

    To the point of my post – at work I use “Eclipse”: for Java development with “Subclipse”: which builds version control right into the editor. You can browse repositories, do diffs and pretty much anything you can do with Versions or Tortoise. It’s excellent. At home I also use “Aptana”: on a mac (as I do more script work at home) which is built on eclipse, so I can use the same Subclipse plugin at home too. Eclipse/Aptana are written in Java so run on macs and PC’s and are open source – so it’s a great editing tool all round for me. It’s flexible too – you can install eclipse and get an Aptana plugin or just install Aptana on its own. I highly recommend it for back-end server-side development and front-end web development needs and especially recommend it for simple SVN integration.

  21. Ok, I understand your point on SvnX and I agree with learning people to use svn CLI to better understand Subversion. (Anyway, my comment was a bit subversive 😀 )

    I do also use Eclipse which is to my opinion one of the best IDE ever which integrates all languages and tools (because of a pluginable architecture).

    Eclipse (with “Aptana”: , “Subclipse”: , “Flex”: , “Sysdeo”: , “Mylyn”: plugins) permits me to code front-end (AJAX/HTML/Javascript/Flex/AS3) and back end (Java EE/Tomcat/PHP), linked with “scm”: (subversion – “trac”: – “bugzilla” – “Jira”: ), and also debug the whole application (backend + frontend) in the same environment which is one of several added values (like being a platform independent software).

    BUT, it is quite developer oriented and I would not expect from a web designer to be able to use such a tool in a natural manner.

    Anyway, thank you for the article on subversion. I know so many web agencies which work without any versioning tools. At end of projects, there are always file like and it always got on everybody’s nerves to search for the good version.

    Questions :
    Do they teach about versioning in web design schools ?
    Don’t you think that any computing related studies should include a course on versioning and how to work better/faster ?

  22. bq. Questions : Do they teach about versioning in web design schools ? Don’t you think that any computing related studies should include a course on versioning and how to work better/faster ?

    That’s a great question. I didn’t go to school for new media or web design, so I don’t know. My guess would be that most schools don’t teach it. But I’d encourage others to chime in on that.

    I think a course on workflow would be helpful and that should include talking about version control.

  23. bq. I think a course on workflow would be helpful and that should include talking about version control.

    That is what I should have write 🙂
    Learning versioning without any workflow concerns is irrelevant.

  24. one of the main advantages of subversion for me is that it is well integrated with most tools that i use:
    Editor: BBEdit has built in svn-support so I can commit, diff, merge and view logs from right within the editor. The same holds true for eclipse of course.
    Project mangement: we work with freelancers from all over the world (germany, india, italy, us) for coding and webdesign (yes we are one of those small web-outfits…) and use trac for managing our projects. Trac is also very well integrated, so you basiclly have one website per project where you can see all the tickets that are being worked on, and a very convenient view of the project’s history in the codebase. All svn commits are neatly listed and displayed with all the code changes instantly visible.
    This setup (svn, trac, eclipse, other editors) has turned out to be a very successful workflow for a number of projects from small to large in the past year so I can highly recommend svn even while it may not be bleeding edge. It just gets the job done. Also: al of our freelancers already used and knew it, so no problems with integrating new members into projects.

  25. I’ve switched all my personal stuff to mercurial – when I’m away from internet, it’s nice to still be able to commit changes in my local working repo, then push them back to my main repository when I get back to the world.

    Having come from RCS -> CVS -> SVN, the fact that most Mercurial commands have the same syntax as the SVN ones makes me happy.

  26. I used SmartSVN for the Mac for years, until I switched over to git. It has a good interface and wizard for connecting to new repos. If you are using git, I highly recommend using GitHub.

  27. There’s a TextMate bundle called _svnmate_ that integrates all the Subversion functionality into the world’s best text editor. Very very useful.

    Although after reading these comments I may look into Git; sometimes I’d love to be able to branch, and Subversion either can’t do it, or (more likely) doesn’t make it easy enough for me to figure out.

  28. I find it funny all those discussions about which SCM system is best.

    At my company we use Subversion… and the reason was pretty simple… it can be accessed in many different ways (either through the command line, through a specialized GUI or even hidden behind a “Shared Folder” under windows or Mac).

    But the biggest reason why I think Subversion is great as a collaboration tool is that it allows *anyone* to use it (heck, even my mom was able to use it after a 10 minutes training and she’s pretty “un-literate” when it comes to computers)

    If you’re using it as *the* collaboration tool for your organization you have to stop thinking about source code and developers and start thinking about graphical objects, PDFs, PSDs and graphical designers, project managers and copywriters…

    From that standpoint, SVN is still the best in my mind.

  29. For those of you who prefer to work with PHP rather than ruby, you can find a script that will post to Basecamp here. Not as difficult to set up as it first looks.

  30. Have any of you tried out “DropBox”: ? It seamlessly syncs a special folder and all of its subfolders with all the computers you connect to it via amazon’s s3 servers.

    It’s really amazing, you can designate collaborators for specific folders, and it has version control. All files are saved locally to your hard drive, except previous versions.

  31. I use Subversion for all my projects, not only with clients and sub-contractors but also with some of my own stuff.

    Lately I’ve started using Subversion to work on some of my longer blog articles, that way I can continue writing from my desktop or laptop and keep everything at hand in my server.

    After reading the comments about git and bazaar I think I’ll take a look at those options.

  32. While the basic points about needing a version control system are sound, subversion itself is obsolete. The world has moved on to distributed version control systems like git (or perhaps mercurial).

    Certainly you wouldn’t start a new project using subversion — it’s only appropriate for legacy setups where making a switch to a modern setup needs to be delayed for some reason.

  33. While the basic points about needing a version control system are sound, subversion itself is obsolete. The world has moved on to distributed version control systems like git (or perhaps mercurial).

    Certainly you wouldn’t start a new project using subversion — it’s only appropriate for legacy setups where making a switch to a modern setup needs to be delayed for some reason.

  34. “As the subcontractor’s employer, you have every right to stipulate deliverables, the tools used, and how and when the work gets done. Your subcontractors will appreciate a solid workflow and know that you have your act together.”

    I suspect this statement would not stand up within a court of law, at least not in states like California which distinguish between the rights of employees and those of contractors. Even if a sub contractor were to sign a contract surrendering his/her rights about how work gets accomplished, I’m not sure if that contract would be enforceable.

  35. There is no software for mac to replace a PUTTY and SVN Tortoise – combination (Yes, I have searched in Google and I find all this SVNX and others to be really unusable). Plus, I find SVN itself extremely hard both to install and to manage. From my experience I can say that using SVN doesn’t worth the time you’ll have to spend to get it working and to keep fixing it.

  36. For those of you that feel SVN is obsolete, please look into VisualSVN Server as well as TortoiseSVN — these free tools make SVN very very easy.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA