Backblaze and Subversion, Time to Change?

By | November 6th, 2014

Our recent post on Source Code Control led many to ask, what does Backblaze use? The short answer is Subversion (SVN). The longer questions are: why did we pick it, how has it worked out, and should we switch?

What Most Companies Use for Version Control

According to the folks at Duck Software Open Hub (formerly Ohloh.net), Backblaze is not alone in using SVN; in fact, SVN is still the most popular repository among the registered Open Hub users as you can see in the chart below:

blog-source-control-share2

Why SVN for Backblaze?

Backblaze has used Subversion since we started in 2007. It was selected and set up by Brian Wilson, our CTO. On his personal blog, Brian, documented his experience in getting Subversion up and running for Backblaze. Some of the article specifics are a bit outdated as the server used was running Windows Server 2003, but the overall process still works. As a side note, the Dell Optiplex server Brian used was only recently retired from service.

Brian chose SVN for Backblaze even though he had not used SVN before. Previously he had worked with Perforce and CVS. Using Perforce was out because we would have to pay for the licenses and when you are bootstrapping a company from your own pocket, such things are luxuries. He asked around and several of his friends suggested SVN. In mid-2007, SVN was becoming well known in the developer community, while CVS seemed to be languishing. In hindsight either choice probably would have worked for Backblaze, but Brian went with SVN and never looked back.

Brian installed and used SVN even though at the time he was the only engineer. Why? Rule #1 of Brian’s 10 Rules for how to write cross-platform code, “Simultaneously develop – don’t port.” He would write code initially on his PC, check it into Subversion, and then check it on his Mac to make sure it worked. This allowed him to quickly develop our cross-platform “base” libraries (Rule #5) that we continue to use today.

Our Experience Running Subversion

As Backblaze has grown since 2007, not only have we added more engineers to Subversion, but we’ve also had more departments get on board. Today, our tree manages contributions from engineering, operations, web development and even marketing. Subversion has been a good fit for Backblaze as we are fairly linear in our development practices. We rarely (if ever) branch our code, instead adding things in a continuous fashion. That’s not as crazy as it seems, as noted by Martin Fowler, a self-described champion of continuous integration:

“Subversion encourages a simple central repository model, discouraging large scale branching. In an environment that’s using Continuous Integration, which is how most of my friends like to work, that model fits reasonably well. As a result Subversion is a good choice for most environments.”

“If It Ain’t Broke…”

I polled some of the engineers at Backblaze to get their sense as to whether they’d consider changing from Subversion. There was some enthusiasm for moving to GIT and a couple of votes for Mercurial, but the most prevalent sentiment was “if it ain’t broke, don’t fix it.” There was also a realization that at some point change could be inevitable as the team continued to grow in size and product continued to increase in scope, but right now the team can still “Grok” the system using SVN.

Would You Switch from Subversion?

On the Stack Exchange network there is a great discussion on why someone might consider changing from Subversion and consider another system (mostly GIT or Mercurial in this case): http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-should-i-consider-or-not-consider-mercurial-or-git-or. The discussion is a couple of years old, but still worth reviewing. In addition, the discussion includes references to other resources worth reading as well.

For the moment Backblaze is sticking by Subversion, but just for fun let’s make you the Backblaze CTO. As CTO, you are charged with looking into your crystal ball to determine what we should do over the next couple of years. Below are a handful of high-level requirements to get you started.

  • The version control system should be open-source, but reasonably well supported by the community.
  • We don’t branch very much today, not because it’s hard with SVN, but because we don’t need to branch very much.
  • We have well defined teams for the mac client, windows client, server functions, operations, and mobile services. Code check-in conflicts do not occur very often and when they do they are mostly obvious and easy to solve.
  • About 10% of our engineering group lives and works out of state, visiting our headquarters in San Mateo once a month or so.
  • We have non-engineers (i.e. marketing and operations) using SVN today.

Based on your experience, what other things should we be considering? What source code control system do you use? Why did you choose that one? Is it everything you thought it would be? We’d love to hear your thoughts.

 

Andy Klein

Andy Klein

Director of Product Marketing at Backblaze
Andy has 20+ years experience in technology marketing. He has shared his expertise in computer security and data backup at the Federal Trade Commission, Rootstech, RSA and over 100 other events. His current passion is to get everyone to back up their data before it's too late.
Category:  Backblaze Bits
  • Chris Sherlock

    You don’t need to force anyone to change their ways, to be honest. If I was working for you guys though, I’d be using git svn on the sly :-) And you’d never know it!

    https://git-scm.com/book/en/v1/Git-and-Other-Systems-Git-and-Subversion

  • Gilbie Rivas

    Useful blog post . For what it’s worth , if someone are looking for a service to merge PDF files , my business found a tool here ALTO-Merge.

  • Nick P

    My focus on high assurance systems keeps me on security-enabling, centralized designs like hardened Subversion, Aegis, etc. So I avoid DVCS. Similarly, you might not need it but they’re right that you should try it: lets you start getting long-term ROI out of a potentially better development flow and lower SCM-related risks. However, I’d recommend Mercurial over Git because Git has serious design issues:
    http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

    Not sure if any of these have been fixed since. Yet, seeing flaws of this sort make me not want to waste time on a tool where developers didn’t invest time into making it comprehensible, consistent, and safe. Tools shouldn’t get in their users’ way, imho. Previous SCM systems I used didn’t. Git does. Mercurial not so much, although DVCS to VCS is still a learning curve. So, I’d say start with Mercurial and switch to Git only if you need its advanced features.

  • My take on the SVN vs Git is simple. Software development is all about cycles within cycles. E.g. write a change, compile, test change, repeat. In the SVN scenario you’re tied to performing many of these change cycles before you can commit your changes. The act of committing and sharing software with your team are tightly coupled. In the git mindset, these two things are seperate. This separation allows you see the software development activity as a continuous series of small bite sized experiments / changes, rather than a smaller amount of larger experiments.

    “We don’t branch much…”. Realistically you do branch every time two people are working on copies of the master. Git just makes it more explicit (if you want).

  • adnamsale

    My experience is running small-medium dev teams over the last decade+. During that time I’ve used Perforce, SVN (briefly), Mercurial and Git in roughly that sequence. I’ve always need basic branching support so that we can develop long-term new features alongside bug fixes to existing releases. My main conclusion would be to agree with the ‘it’s just source control’ argument. None of those SCM changes has had any significant impact on productivity, positive or negative. No change has ever recouped the time taken to rebuild our CI and release processes.

    That said, I would view Subversion as something of a liability just because of its age and if it were my team I would be planning a move to Git at some point. It won’t open any magical doors or make you view software dev in a whole new light, but it will give you a modern, very actively supported toolset. I think the only requirement you have that argues against Git is the requirement for non-engineers to use it. I’m largely a command-line user and even simple operations can require the most arcane git commands. However, you can hide most of that behind the excellent Sourcetree UI from Atlassian and the overwhelming dominance of Git still gives it the edge over Mercurial for me. Finally I’d agree with the recommendations to go with BitBucket or GitHub for hosting; not needing to maintain and backup a server was the motivation for moving our last holdout project away from Perforce.

  • UncleZeiv

    It’s funny to read the same things I used to say before switching :) Switching takes some time, also because Git is not super-user friendly. Having said that, I immediately saw benefits even as a solo developer!

    One thing I would recommend is for the more curious of you to check out git-svn. It’s a bridge that lets you have a local git repository that communicates with a remote svn repository. It’s not incredibly polished, but it will let you benefit from: local commits, multiple local branches, reordering commits, etc. and I found it very useful to get familiar with git while still being a good citizen of an svn environment.

    The strongest argument I have in favour of git is that I basically never ever heard from anyone that has made the switch who would like to go back. It’s just _that_ better.

    Good luck with your new adventure!

  • Daniel C. Daugherty

    I would like to think, right between Subversion and Bazaar, there is a single lone ‘1’ for Visual Sourcesafe. And that 1 would be me. (disclaimer: I use Git as well and will probably use AWS Code Repository going forward. I’m not sure if anything AWS appeals to those who DIY but Git is nice for the way it efficiently stores deltas)

  • SPFox

    I’ll just echo what other are saying that unless you’ve actually used a DVCS you probably aren’t gonna really understand the benefit. I first used version control back with RCS (pre-CVS/SVN/git/hg/etc/etc) and then on into CVS. The jump from CVS to SVN was an obvious one as CVS sucked in obvious ways that SVN fixed. I resisted DVCS for a long time since I also didn’t really see the benefit. Lots of new stuff to learn and the current tools I was using seemed to work fine for a paradigm that had served me well for 20+ years. I’m pretty conservative tech-wise as jumping on the latest fancy new thing is usually a mistake long-term. But Joel S. and others all swore DVCS was worth it so I took the plunge 2 years back and moved the main repository for our group from SVN to Git. The learning curve took a bit (highly recommend the free desktop GUI tools from Atlassian), but now that I’m living in Git I would never ever go back. I set up repositories even for personal projects where I’m the only developer. I commit many times a day and branch freely (often several time a day) and that’s just within my own local pile of code. It really changes the way you think about your code, reducing a mental load that I didn’t even realize was there that was holding me back from being as creative and aggressive about refactoring and doing things right without fear of ‘breaking that which already works’. Please try DVCS. Git’s the obvious choice simply because it’s got a larger market share and so it’s more likely new staff will already have the skills in hand when they come through the door. The differences between Git/Hg and the others are tiny compared to the move to DVCS in general.

  • pan

    It seems to be working for you.

    I think it will take a long time to recoup even the small cost of switching and, assuming that your development efforts are planned and coordinated, you won’t see any substantial benefits or differences, particularly if everyone is doing continuous integration (as they should).

    If the use of your SCM solution is a significant time / effort cost to your development effort, you need to fix the process and not the tool.

  • Nick Kaijaks

    I used to be a big svn fan, and when I moved job, it hurt to find myself in a place still with cvs. Soon after though, we migrated to git, and now I’m totally sold. We use locally hosted Atlassian Stash (https://www.atlassian.com/software/stash) which gives us a feature-rich, GitHub-like environment.

    To echo what others have said, the ability to switch with very low friction and use feature branches atomically is surprisingly useful when you get used to it. If my director comes along and says “stop that ticket, work on this super-urgent fix now”, I know that I can park what I’m doing and be confident that it won’t be epic trying to move there and back. We branch-per-ticket for all but the most trivial edits now, and it gives real clarity on who did what, why, and when.

    The other key benefits for us, which haven’t been mentioned already, are really in the tooling. Stash (like GitHub) gives you pull requests. Even in a small team, the ability to conduct near-concurrent code review with inline commenting is fantastic for improving code quality. Sadly, it’s not a magic solution for finding bugs (good BDD/TDD practice is usually better for that), but it really helps ensure that what’s committed is clean, readable, and consistent with our code style. Especially when you set it to block merging until someone’s reviewed and approved it first :)

    I personally also use SourceTree (http://www.sourcetreeapp.com – free!) which packages elegant visualisation of feature branches as well as a good diff/merge tool. Many other visual clients are available, and the CLI is all-powerful when you need it.

    You may find the story of Atlassian’s migration from svn to git interesting: http://blogs.atlassian.com/2013/01/svn-to-git-how-atlassian-made-the-switch-without-sacrificing-active-development/

  • pjv

    This is a meta-comment on this whole discussion. Speaking as someone who moved from using SVN to DVCS (both mercurial and git, though I have now standardized on git) a few years ago, I assert that you can’t understand the paradigm shift without actually diving in. How it was for me is that before I had a fair amount of hands-on experience with DVCS source control, I could not help trying to understand it from the perspective of what I already knew: SVN. But you just can’t get here from there.

    It took working with mercurial and git enough to leave behind SVN conceptually before I could really understand how DVCS’s work and more importantly, how they change your coding workflow, massively and without question for the better.

    From skimming through these comments, I’m pretty sure that Brian is in a similar place to where I was when contemplating switching. I don’t think any amount of explanation or argument is going to make much difference for him because without spending a good deal of time actually using a DVCS, I think he will keep looking at it from within the same source control paradigm that he is used to and just not see a compelling difference. It’s like trying to explain the color red to a blind man (no offense meant).

    There was a comment below from Brian about it being “just source control”. That made me LOL because I could have, maybe even did, say the same thing. All I can say to you is having made the switch, I could never say that now.

  • MattFlower

    5 reasons, coming from someone who has moved from subversion to git twice voluntarily:

    1. Your working on some code, someone stops by your desk and says “hey, this is broken, can you help?” In subversion, a solid developer has a few second solution to have a clean repo. This is probably some tool they built themselves. Git stash comes on every developer’s box.

    2. Are you on a plane without wifi? You aren’t going to be switching branches, checking history, or anything of the sort with subversion. You can do this just fine with Git. With subversion you have to log into the vpn just to get a decent log.

    3. Merging isn’t just something you deal with when you are branching. Has someone committed while you were working locally? Resolving that means merging. Did two people commit in that time period? That’s an even messier merge. Git’s internals naturally resolve merges better than subversion. Sure, subversion has improved a lot over the last 5 years, but it still has a long way to go.

    4. With git you have a full copy of your repo on every developer’s box. Heh, oh wait, you’re BackBlaze, I’m thinking the “infinite backups” arguments is less powerful there.

    5. Git has rename tracking, I found that in Subversion I always regretted renaming things due to the history loss.

    None of these things are a killer, they are just a bunch of tiny inconveniences. Why let those add up?

  • andyjeffries

    The funny thing is – when I read this article and the ending questions, my first thought was “I didn’t think this was still a question”. I thought DVCS and in particular git had “won” the source control world.

    I agree with the other posters, you say branching isn’t a problem for you because you rarely do it, maybe you have got in the habit of rarely doing it because it’s a pain. Now you don’t notice the pain because (like Pavlov’s dogs) you’ve been conditioned out of doing it. If you move to git you’ll find it really easy so maybe it will become more of your workflow.

    For example, at the last two places I’ve worked (including this one, where I introduced it), we have a script that runs in Jenkins as a job, that itself communicates with our git server, finds all the current branches and creates a CI job for them. Then it does a sweep to remove any CI jobs (matching a certain pattern) that are no longer branches. So developers can create branches any time they require, even if just for a few hours, know they are being checked by CI still and then remove the branch when it’s all merged and know that CI will blow its jobs away too.

    I did find it very interesting that you quoted Martin Fowler on how Subversion is a good fit, when that article was written in 2010. 4 years is a LIFETIME in web terms. To bring things a bit more up to date:

    “In recent years I’ve had more colleagues and friends write articles on my site using the toolchain. To work with them I set up a stripped down copy of my core website repo and we collaborate using **git**. *Since my collaborators are mostly programmers this workflow is pretty effective.*” — http://martinfowler.com/articles/vagrant-chef-rbenv.html (4 September 2014)

    Martin’s moved with the times, using Git, Chef, Vagrant, etc…

  • mike

    PLEASE focus on a Linux client. You can use SVN or Git or whatever you want for change control. I only care about our experience as end users, and I have been waiting for a Linux client forever :)

    • mike

      Related moreso to the post… SVN is definitely easier to grok. We have moved from SVN to Git, and lost some of our most advanced Git users, so there are some times that we wind up messing something up due to Git’s advanced capabilities. Ultimately I believe it is better than SVN, but you need to understand it enough before it becomes “better” – otherwise it’s just a more complex way to do part of your core job.

  • I migrated our development team (flightaware.com) from CVS to git in 2010 and looking back I can confidently state that it was the single-most significant boost to our productivity and code quality that we’ve ever experienced. Moving to a distributed version control system that made branching and merging painless was transformative to our development pace, our release engineering process, and our developer happiness and job satisfaction. I’m still actively involved with a number of open source projects which still use SVN and whenever I have to interact with those codebases I feel sort of like I’m trying to type while wearing mittens. Thankfully, git acting as a front-end to SVN is well-exercised code and allows me to maintain some of my sanity. Everything Reefiest has said already rings very true to me, and I love the Spolsky article. I also think that it’s an hour well-spent to watch Linus’ talk to Google engineers: https://www.youtube.com/watch?v=4XpnKHJAok8 which I found very compelling.

    • > single-most significant boost to our productivity and code quality

      Geez, it’s just source code control. I don’t really see how it could boost productivity or code quality. Heck, I suppose if it CORRUPTED files on checkin it could lower code quality? Developers shouldn’t be interacting with it more than a few minutes a day. Checkout in 30 seconds, spend 6 hours working furiously to edit files, compile, when finally ready testing for another few hours, checkin for 30 seconds writing a comment about what you did. Maybe every few months a problem occurs where we need to look through the checkin history.

      • Don’t discount the benefit of very granular commits and frequent merging. With git we’re able to branch and merge for specific feature development or speculative development in a way that CVS/SVN deters. This has resulted in better developer collaboration, better code documentation, and more effective debugging and regression testing. It’s also allowed us to move to a master/staging/production branch release infrastructure which yields better internal code testing and easier emergency code patching to production.

        Most of our development takes place in feature branches now (single developers or teams) which are merged into a master development branch as appropriate. Each night the master branch is merged into a staging branch, which our employees use each day to internally test the code. Each night the staging branch is merged into production branch and deployed on our public web servers. Emergency changes committed to master can be “cherry picked” into staging or production or both if we need to bypass the release system.

        It’s a robust workflow that has resulted in much better quality code which is better tested. Trying to do this sort of workflow with SVN or CVS would be impractical because of the branching and merging limitations discussed elsewhere in this thread. It has truly been a transformative switch for us and I can’t overstate how beneficial it’s been.

        Plus the ability for teams of developers to collaborate in feature or bug fix branches without any drama has sped up our development pace even as we’ve grown the dev team. Tools that make it easier for developers to work together, share effort, and coordinate their individual activities are a direct boost to productivity.

      • > Checkout in 30 seconds, *spend 6 hours working furiously to edit files*, compile, when finally ready testing for another few hours…

        I’m sure this was just a dramatization and that you don’t believe that developers spend the great majority of their day “furiously editing files.” I know that you know the real work in building software is though-work. Though to be fair, most of the world, and many in the industry itself, seem to believe writing code to be the thing which takes the most time. :wink:

        I think this tweet sums it up best: https://twitter.com/garybernhardt/status/195257232156409857

  • Reefiasty

    “We don’t branch very much (…) because we don’t need to branch very much.” – that is something a SVN user would say: you said it yourself, you don’t think SVN is broken. But it is. Let me quote a good book on the subject, written by Joel Spolsky (the guy behind stackoverflow and trello). In the book he explains how to use Mercurial and there is a special chapter dedicated to people who used Subversion before:
    “(…) if you’ve been using Subversion, your brain is a little bit, um, how can I say this politely? You’re brain damaged. No, that’s not polite. You need a little re-education. (…)”

    This shocked me. I could not believe it myself, but a few chapters later, I realized the truth: I have been brai… uh… I needed re-education myself. Read the whole thing at http://hginit.com/00.html

    git blazingly-fast, feature-rich client can be used with a subversion repository. You do not need to switch the whole organization to git with all the pains that such migration might cause. Just tell the devs that it is okay to use the git client if they want to (with subversion as a central server for now) and then just… wait.

    +consider using github instead of hosting the server yourself. Really.

    • Andy Klein

      Just the kind of info we’re looking for. We looked at Joel’s stuff, not sure we completely agree, but then again we’re using SVN so would we? Still “brain-damaged” I guess. Truth is we really don’t branch and don’t miss it. Still not sure where/when we are going, hence the reason for the post, appreciate the insights and the affirmation of the Spolsky POV.

      • Reefiasty

        Thanks for the feedback.

        I can also recommend a git explanation by Linus Torvalds:
        https://www.youtube.com/watch?v=4XpnKHJAok8

        he addresses many points very relevant to your situation in this talk.

      • Vetle Leinonen-Roeim

        I used CVS for a while, then SVN, and now Git. I must agree with Reefiasty (and Spolsky), there are some fundamental differences that make Git not just a SVN alternative, but altogether a much better tool.

        Sometimes something that isn’t broken needs to be upgraded to make life easier. You need Git, you just don’t know it. :)

    • > because we don’t need to branch very much.” – that is something a SVN user would say

      I think organizations of different sizes have different needs. When I was all alone at Backblaze, branching makes zero sense. But 25 years ago at the start of my career, I worked at Hewlett-Packard when they had more than 100,000 employees – and branching was very, very important to provide stability for releases.

      It also matters your style of programming. I have personally always preferred to check in every day or as close to every day as possible. (Continuous Integration?) I try to do incremental changes that are self contained and still keep everything compiling and working well. But I understand some people like to avoid merging with the tree for months at a time, then to a massive merge. I think for those engineers they might gain more from something like GIT than I would.

      • Reefiasty

        Consider this:

        When developers code for a full day without committing, do they ever have a moment when they think they may need to revert some of the recent changes to implement something in a different way? But then, from time to time, after Undo’ing it with ctrl+z and implementing the second version, it turns out that the first version was better, and now (since it is gone) it has to be written again. Alternatively one can be cautious enough to backup the modified files (manually or using some tool) before reverting them.

        Now if those changes were all painlessly (and instantaneously: done before a spring in the keyboard has time to retract the enter key after it was clicked) saved in git, one could switch between them at will (with similar speed). One could revert or restore any portion of work which one quantified as a minimum quantifiable amount of work. Like IDE Undo, but across the whole source tree, with Redo capability and full memory of those (quantified) changes.

        I tried to describe something svn is terrible at and git is good with, not sure if I got it right :)

        As for hosting the git server yourself, three years ago I said almost the exact thing you just did (ok, 10GbE was not so popular back then). I can now only say that I regret not using github. They request a silly amount of money and everything just works OR one can pick and host a git server (gerrit was the best option for me at the time), but as with any software, one needs to get experienced with it to be able to fully manage it. That will take some time, which I truly expect to be of more value than the silly github plan price. Github adds issue tracker, code review, pull requests, API integration with external tools etc. There are open-source alternatives for all of those, but they will never integrate as well as github does and learning to host them will simply cost man hours. I believe that from a financial standpoint, hosting own git server is an expensive choice.

        • > they think they may need to revert some of the recent changes to
          > implement something in a different way?

          It’s true, it has happened to me. :-) But personally I don’t like complicating the main “common” development path in order to support something that happens rarely. Most of the time I know I’ll like the fix and I implement it. More rarely I know it is a dodgy fix and I keep an old copy of the tree and avoid checking in until I’m 90 percent sure it’s the right direction. If it is the wrong direction I keep the changes moved aside on my local disk and start over with the original tree. AND THEN ONCE EVERY TWO YEARS I regret losing a section of code I wrote, then threw away.

          But it’s just code, I can always rewrite it from scratch. If it really was that amazing, I probably stash it away in a file in the subversion server that isn’t part of the main compile, like “alternative_implememtation.txt”. Yes, these are all work arounds, but for me, the occasionally work around is fine. It doesn’t absolutely demand I get a different tool for the job. (Switching tools incurs a time penalty each time, it needs to save enough effort in the long run to deserve the pain of switching.)

          Don’t get me wrong, GIT has a LOT of support in the world, and as time goes by and more and more people are familiar with GIT then it will become a fine choice of source code control. Backblaze would have survived fine on Perforce, on CVS, Subversion has been good to us, and Backblaze would survive fine switching to GIT, then switching again in three or four years as something new has gained traction.

          • The thing is, git doesn’t complicate. It simplifies. I understand the resistance to switching, especially as there is a small learning curve as you get used to the “git way” of doing things, but trust me when I say it makes your life way easier (even on single-developer projects).

      • “I have personally always preferred to check in every day or as close to every day as possible.”

        Wow. Just, uh, wow. That’s terrifying to read. You really do have no idea what you’re missing with a git/mercurial distributed approach. With a good distributed revision control system you could be committing dozens of times throughout the day without impacting other developers. Having a more granular commit log makes it far easy to debug regression bugs, bisect to isolate specifically which code change introduced a bug, and change course during the development of a feature.

        I know you said at the beginning that you don’t really have any use for branching, but you should realize that by withholding your commits all day long you are, in effect, branching — you just don’t call it that and your branch suffers from having no version control protections. It’s a de-facto branch you’re just doing it by hand in a tremendously sub-optimal way.

        Imagine if your tools allowed you that flexibility with ease and without having to forego the benefits and safety of version control during your workday? Switch to git, give it a month to really gel, and you’ll come back to this post and be amazed at what you said here.

        Waiting a whole day before making a commit is a MASSIVE MERGE. This is exactly the sort of brain damage that Joel is talking about. :)

      • Nate Bird

        I would recommend Gitlab (https://gitlab.com) for internal Git hosting. Then you host it yourself and get all the wonderful benefits of git.

      • I can’t recommend GitHub enough. Not because they’re a Git host – which they do very well – but because of all of the value-adds they layer atop Git.

        Pull Requests are a HUGE boon for teams; the low barrier means code reviews can happen for every change to your system. The integrated social features (like @mentions, issues tracker, PRs, wiki, etc…) for talking about the what, why, where, and when of building products has been so very valuable to teams I’ve been a part of. They also support SSH and HTTP access to the code, making it super easy to set up. They have great GUI clients for Mac and Windows for non-technical folks who need to edit docs and such. Or they can even edit such things right from the web UI. And for any of your devs who are determined to stick with SVN, GitHub provides a Git SVN bridge (seriously!).

        I’d also echo some of the other commenters’ posts re: dev practices of small, atomic commits, cheap branches, and things like rebasing, cherry-picks, bisect, etc… These are tools I use all the time. Tools I didn’t know I needed until I learned they existed.

        Also consider the recruitment and retainment angle. Git is a widely used and very popular tool amongst developers. It’s a tool many folks want to use, and for anyone who’s learned to use Git effectively, tools like SVN can seem antiquated and kludgy. Skill acquisition is just about doing your current job better, its also about your next job and the value you can deliver in the marketplace.

        Oh… getting back to GitHub specifically. I’ve worked on some teams that could not use the GitHub.com service. Luckily there’s https://enterprise.github.com ;)

        I’m sure SVN is working for you. But I have every confidence that a distributed SCM would allow your teams to work even better. ;)

  • ujay68

    To get you and maybe the team accustomed to git, you can use both. Me, eg, I often use a machine-local private git repository on top of working directory of the central svn repository that stores my team’s code. In git, I can do daily commits to save larger code works incrementally that I only want to commit to the central svn repository after some time when these are tried and tested. Or I use git temporarily to stash away pending changes for a new feature when an urgent bug fix has to be done. You could even set up a small collaboration of a few team members working together on a new feature in git and only later commit this into the central svn. And when everyone’s happy with git in this way, you can switch completely … ;-)

    • Candace Bain

      I’m curious if you run into problems getting out of sync with the main SVN repository if you commit to it less frequently? I can see that it would be useful to be able to temporarily set aside local changes, this is interesting.

      • ujay68

        I didn’t experience sync problems to be more severe than they would have been without the git approach. It’s not that I commit less frequently into the central svn repo but that I use git as a kind of temporary vcs during the time when I cannot commit to the central svn anyway (eg, because I’m doing major refactorings that take like a week and that I want to commit into the central svn in one single step). And then, we still and always have the human sync in our team and with the product owner, so we try to organize all code changes in a way that is least likely to cause code interference and commit conflicts.

  • Justin Winokur

    This is a very interesting post. As I commented last time, I use Subversion. For my usage-case, Git may actually be better except for one glaring difference; my boss/advisor knowns SVN and doesn’t know Git. Then, of course there is the reason a lot of people use older software; it’s what I know. I have SVN set up just so and I am pretty good at command line usage.

    Also, I am grad student so I will be moving away from all this soon enough. If I were in it for the long haul, then maybe I would consider the move.

    I do backup my subversion daily. It is on a central server. I run a script to first dump the repo (incrementally so I am not doing the whole thing every time), then I use rsync to pull it to my mac. Finally, it gets backed up on my mac via Backblaze and Time Machine. All in all, I have 4 to 5 copies of my repos.

    I use 3 repos since they are for very different things. But this makes me wonder a few things about the BackBlaze usage.
    (1): Is everything on different folders of the same repo or are they on different repos
    (2): What is your SVN backup strategy?
    (3) Out of curiosity, what is your latest revision number?

    • Candace Bain

      I’m a developer at Backblaze and can answer a few of these:

      1) Currently everything is in the same repository, I imagine this could change over time
      2) I’m not sure about this one other than knowing that the server *is* backed up
      3) Looks like 26390

  • durangoodyear

    Sounds like you need to talk with Atlasssian about the benefits of GIT for remote workers…