Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've recently noticed a bit of a trend for my projects as of late. I use to run my own SVN server on my VPS, but recently the nail went in the coffin for that when I got my last project migrated from my server to a Mercurial repo on Bitbucket.

What are some of the ramifications to this? (disregarding the change in version control systems)

It seems like there has been a huge explosion in version control hosting, and companies like Bitbucket even offer private repos for free, and Github and other such services are extremely cheap now. Also, by using them you get the benefit of their infrastructure's speed and stability.

What reasons are there these days to host your own version control? The only real reason I can think of is if your source code is super top secret.

share|improve this question
    
I get the feeling that everyone else has an internet connections which is up 100% of the time, infinitely fast and uncapped... Other than that, most large companies' schedules are such that even a small delay / disruption in development or releases would cost more than running your own VCS, with redundancy. –  Daniel B Oct 3 '12 at 8:27
    
@DanielB - Part of the reason for the explosion in hosted VCS solutions is the move from Centralised VCS to Distributed VCS - you don't need to be connected all of the time, only when you want to push/pull. Even if your Internet is down you can push/pull with peers on your local network rather than going through bitbucket/github or even push/pull to a memory stick if your local network is down (I've had to do this!) - such is the power and flexibility of using a DVCS. –  Mark Booth Oct 3 '12 at 14:16
    
@MarkBooth I realise that (I use them myself), but I wouldn't want to coordinate that in a pinch. All I'm saying is that in a country where internet is quite slow, often down, and very expensive, a hosted solution isn't the most attractive, especially considering how trivial it is to set up a git / Mercurial box. –  Daniel B Oct 3 '12 at 17:41
add comment

2 Answers 2

up vote 4 down vote accepted

Avoid using a third-party hosted version control system when:

  1. The code is under NDA or otherwise has contractual or legal obligations that the hosting provider cannot or will not enforce. For example, code hosted externally may have issues with Common Criteria certification (this may or may not be an issue but source control was discussed in projects I have been involved in).
  2. The code contains unfiled patents, trade secrets or other intellectual property that the hosting provider cannot or will not protect.

Other things to consider when using a third-party hosting provider:

  1. Does the hosting provider support the version control system you are using? Conversion is possible but often complex and difficult. (This was mentioned in the question but it is included here for completeness)
  2. How are you billed for the service? Are there limits or thresholds such as repository size limits, bandwidth caps or throttling, user caps? Most providers are relatively cheap but be sure to work out how much it will actually cost before using the service.
  3. Does the hosting provider update to newer versions frequently? If not, are there features in newer versions you require? If they do, are there incompatibilities between the newer version and the version you are using now?
  4. Does the hosting provider meet your uptime or bandwidth requirements? If the source code is inaccessible when you need it, what legal options are there to recoup costs? Most systems provide few guarantees.
  5. Does the hosting provider store the source code in a country or jurisdiction where laws may allow others access? Many hosting providers will outsource their storage and servers to a IaaS cloud provider like Amazon but it is still worth asking the question.
  6. Does the hosting provider provide audit logs of accesses, not just modifications?
  7. How do you create and manage users who have access to the source code? Can you delegate this to other people in the organization? Can you access audit logs of user management?
  8. Does the hosting provider provide or enforce strong or multi-factor authentication?
  9. Does the provider enforce encrypted communication, e.g. SSL or SSH? Can you get access to any customer-specific side certificates or keys if required?
  10. How do you "onboard" any existing source code? Can you upload or import history?
  11. When you cease to be a customer of the hosting provider, can you get access to your source code history? If so how and for how long? What happens if the hosting provider goes out of business or merges with your competitor?
  12. How will your needs change over time? Are you likely to need more or less space, users or repositories than you have now? Can the provider handle these changes?
  13. Will your organization need more bandwidth to cope with the increased influx and outflux of data?
  14. Does the existing, on-premise source control system integrate with an authentication service, such as Active Directory? Using a third party hosting provider usually means developers need to remember another set of credentials.

Remember, too, that third party hosting providers are not the "silver bullet" for redundancy. They can be great as an additional, readily accessible backup but few hosting providers will guarantee the backups, at least not without paying more.

That said, third party hosting providers can be great, particularly for a distributed workforce, since they can work on source code without needing VPN access, and it is one less server that needs to be administered.

share|improve this answer
    
15. Will the provider still be alive next decade? 16. Do you need to control the whole production chain, including the exact versions of SCM and compilers? –  mouviciel Oct 3 '12 at 12:32
add comment

External services aren't always stable, sometimes they go down. Github has had a lot of bad luck with downtime in the past few months, out for sometimes hours at a time.

Code may be private. If you're under an NDA or something to not share code with anyone, that includes employees of external services, that can access code in repositories even after they've been deleted.

If you have a large number of repositories (for Github) or a large number of collaborators (for Bitbucket) it can get quite expensive to host them in the cloud. Most agencies who do client work would probably run into this limitation. Much, much cheaper to keep an PC under someone's desk with git or svn installed on it.

That's just what I can think of, off the top of my head.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.