We’re self-hosting SVN on AWS…on our webdev server. Having all of our revision history and development code on one machine, especially one as potentially ethereal as AWS, is terrifying.
You might want to investigate how to to set up an EBS backed persistent root filesystem on AWS as well as how to do S3 snapshot backups. EC2 instances fail. EBS volumes fail. You need to be ready for that regardless of the revision control choices you make.
Is your backup culture really that sketchy? Your source code is probably just one of several digital assets the loss of which would cripple your company. If you don't consider an SVN repository reliable, it might be a good time to check your database backup procedures.
Also, SVN stores a local copy of the codebase as well. If you're working off trunk and the SVN server detonates, all you lose is the history and any branches you didn't have checked out.
We do use EBS, but AWS has a flag for "delete on terminate" where the EBS is automatically purged when the instance is terminated. Not 100% sure of the conditions for this to happen, but when you have a single boolean for something like that, and the only way to configure it is through their command line tools/API, and it's poorly documented, it makes me pretty uneasy.
Edit: We also have a script that takes a daily snapshot of all our EBSes, but we haven't tried to recover them (mostly due to lack of time to experiment).
I know, it does seem the default for "delete on terminate" is wrong. Most people use EBS root volumes in an attempt to gain persistence and a level of protection against accidental termination.
Comments
We’re self-hosting SVN on AWS…on our webdev server. Having all of our revision history and development code on one machine, especially one as potentially ethereal as AWS, is terrifying.
You might want to investigate how to to set up an EBS backed persistent root filesystem on AWS as well as how to do S3 snapshot backups. EC2 instances fail. EBS volumes fail. You need to be ready for that regardless of the revision control choices you make.
Advantage of Git: if your central repository fails, you can recover from any developer's repository.
Is your backup culture really that sketchy? Your source code is probably just one of several digital assets the loss of which would cripple your company. If you don't consider an SVN repository reliable, it might be a good time to check your database backup procedures.
Also, SVN stores a local copy of the codebase as well. If you're working off trunk and the SVN server detonates, all you lose is the history and any branches you didn't have checked out.
You get the same thing with any developer using git-svn...
You can just train the "new tech tolerant ones" in git-svn and don't worry as well.
We do use EBS, but AWS has a flag for "delete on terminate" where the EBS is automatically purged when the instance is terminated. Not 100% sure of the conditions for this to happen, but when you have a single boolean for something like that, and the only way to configure it is through their command line tools/API, and it's poorly documented, it makes me pretty uneasy.
Edit: We also have a script that takes a daily snapshot of all our EBSes, but we haven't tried to recover them (mostly due to lack of time to experiment).
I know, it does seem the default for "delete on terminate" is wrong. Most people use EBS root volumes in an attempt to gain persistence and a level of protection against accidental termination.