Using github as an excuse to stay with svn seems rather ill informed.
You wouldn't lose hours if github is down. You might lose your ability to deploy (if you are deploying from github) but you could setup any other remote you like, and deploy from that.
I'm not sure what the 'size' of your repo has to do with anything...
I think svn is easier and more appropiate for a corporate environment.
Why do you think that git is inappropriate for a corporate environment? I've been using it in one for a few years now and see nothing wrong with that.
git remote add <remote_name> urleven in a corporate lan environment just pulling down an svn repository can take far too long
http://stackoverflow.com/questions/2041/how-do-i-create-a-br...
You can have two separate copies checked out, but you don't have to.
svn doesn't fit the sane modern workflow and everything it does can be done by git in a less painful manner. I think the only use case I can think of for svn is a very binary heavy repo that needs global locking.
Size is mentioned as to be honest we moved a load of stuff to git in 2011 as a test case and it couldn't handle it. We have some test fixture data files (big ones) that it choked on. Not only that, you can't compose software easily without introducing external tooling.
You'd lose all that from using git? Why? Are you saying if you switched to git without switching any of your svn infastructure? We aren't talking about github downtime anymore are we...
> Size is mentioned as to be honest we moved a load of stuff to git in 2011as a test case and it couldn't handle it.
A repo I interact with daily is now pushing 54gb, it contains large test fixtures that have HD videos, and images in it. I've never had any issues. (It takes a while to copy it around...)
heck you wouldn't even really need a remote.
The "single source of truth" is hard to avoid.
Just added a 3 GB file to my github repo. It took <2m, most of which I imagine was spent gzip-ing it.
cringe This is very corporate reasoning in the most pejorative sense of the word.
> Each hour we lose is potentially multiplied by the number of staff as we would push and pull hundreds of times a day.
You clearly haven't used git. Even if github were to disappear, it would be absolutely trivial for a team to switch to an alternative central git repo for everyone to work through.
Except for all the tooling built into github that would have to be replicated locally somehow.
I guess you could switch to: http://www.atlassian.com/software/stash/overview
That wouldn't be "trivial", and if that's the backup plan, you may as well start by using Stash and skip github entirely.
What tooling? The issue tracker and code comments? I imagine the uptime requirements aren't >99% for those, but if you absolutely need them all the time, that's what github's enterprise service is for.
github enterprise is a crappy solution for the above as well and is hard to support and expensive too.
There are better options than Github's overpriced virtual machine-based mess of an 'enterprise' offering.
It is probably prudent to have some central location to push code to though, especially if you want people to work on it outside of your company LAN.
Best solution is probably to have a server you control and have a copy on somewhere like github and keep them in sync. That way you don't have to worry about DDOS of github and you don't have to worry about what happens if a drive dies on your server etc.
Github is usually just this thing for people.
SVN is actually better for us.
I sense a bunch of downvotes coming for me in 3..2..1..
One hammer is not necessarily good for all nails.
- Pull requests and code reviews
- Automatic integration builds of all checkins
- Commit notifications via e-mail
- Browsing of sources via the web
- Sharing of code between collaborating users
DVCS may be "distributed", but organizations and user collaboration are not.
How about also have the code on bitbucket (if you want to use flashy web services). Chances of them going down at the same time seems remote.
> I'm aware of github enterprise
Which I must say is also insanely priced, particularly since you have to pay for everyone with a user account.Which means if you're wanting to use GitHub issues to replace some bugtracker the non-developers need access to you're paying full cost for everyone who might need to update a bug once or twice a year.
I understand that they're trying to get everyone to use their online offering, but a lot of organizations wouldn't consider it due to a combination of not wanting to host their code externally, and GitHub's ongoing uptime issues. They might go for GitHub Enterprise, but it's crazily priced compared to other similar software (e.g. Atlassian Stash+Jira).
git remote add online [email protected]:you/yourrepo.git
Why waste so much time on support infrastructure? Wouldn't it be better to spend that time doing productive work?
That said, it's pretty easy to keep a repo up, so I would guess that if github has a few hours of downtime a year you are still doing better.
I'm available for consulting if you want this kind of uptime ;-D
I'm comparing it to what we have as the suggestion is inevitable.
And that org's infrastructure team could probably claim 5 nines uptime as well.
You could have also hosted an external RCS repository over RSH and you wouldn't have had the problem of VPN provisioning being slow.
The problem was VPN provisioning, not the source control system.
(Good) web services like Github tend to reduce friction, corporate bureaucracies tend to increase friction.
This has nothing to do with Github, other than the fact that Github would let you end-run all rules about data protection, backups, centralized administration of user access, and everything else that you don't individually have to worry about, but the management and IT at the company you work for does.
This is exactly the sort of thing I'm talking about. Let the team working on the code decide who has access to the code. Not some person in a different part of the country who has no idea what the code does.
We have active directory and its all managed there. If someone needs access, their role defines it. If someone wants access they have to ask.
Code theft is a major problem. Not because the code is crap and we're embarrassed (unlike VMware and Microsoft code leaks), but because its valuable.
Do you whitelist or blacklist the internet?
It becomes just as much of a PITA importing projects github and maven for example as well.
We actually ended up sticking with svn and trac and doing manual mirrors of every source dependency we pull in to protect our asses. SVN is kept only due to externals support (even though all our externals are internal!). Our head rev is over a quarter of million revs, 37gb of data and the repository has been online since 2006 to give you an idea.
I'm aware of github enterprise btw - its actually easier to build our own using trac as we can support it end to end, its a crap load more configurable and we can scale it up and run failover nodes easily using svnsync and pgsql replication. We have our own plugins and reports plugged in using reportlab as well. And its not atlassian's crap either.