Switching from SVN to Git: A Startup’s Perspective

http://www.gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/

by jgershen • 16 years ago

42 30 16 years ago

ojbyrne• 16 years ago

Having gone through the same process, for a small company, that "one extra level" is the key. Now I can check my code in early and often without worrying about stepping on anybody else's code. That encourages me to use SCM even more.

mattmcknight• 16 years ago

You can do the same thing with a personal branch in SVN. There was sort of a competing line of thought that keeping it local is a bit of "cave-hiding" behavior. http://blog.red-bean.com/sussman/?p=20

alinajaf2• 16 years ago

While there may be some equivalent in SVN, it gives you nowhere near the flexibility. I can't for example, create an idea branch for one feature I'm working on, try another idea on another branch, delete the first branch, switch back to the second, create another branch off of that and stop midway to checkout master (trunk) to work on something urgent and the then continue development and merge back into master when I'm done.

The equivalent in svn would make me groan, for complexity and for the performance.

Also, the same rules apply when 'cave-hiding'. You should still be committing early and often, but in gitland, 'committing' really means syncing up with an authoritative repo. You can 'cave-hide' in svn by just not committing anything and keeping your changes in your local working copy.

spudlyo2• 16 years ago

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.

a-priori• 16 years ago

Advantage of Git: if your central repository fails, you can recover from any developer's repository.

gte910h5• 16 years ago

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.

bluesnowmonkey• 16 years ago

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.

bkrausz2• 16 years ago

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).

spudlyo2• 16 years ago

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.

dasil0032• 16 years ago

Nice story, but there's no need to categorize a switch from svn to git as optimization, especially as part of the phrase "premature optimization".

That refers to exchanging clarity or simplicity for performance. If a technique is fundamentally superior then it's just the way you should do things, and few things in tech are as unilaterally superior as git over svn.

bkrausz2• 16 years ago

In this case optimization refers to trying to pick the best option. PG talks about it a lot: we could spend hours trying to pick the most efficient desk layout, the best apartment for getting work done during YC, or a hundred other things. As a startup, the right thing to do in most cases is to shut the hell up, pick something, and get back to work. That was SVN for us.

jpcx01• 16 years ago

Shut the hell up? Sorry, that's not really recommended advice to tell your developers.

At least in the Ruby world, if you are on SVN, say goodbye to any competent devs. We can't work under those conditions.

jister2• 16 years ago

“I figured we may as well be one of the cool kids with something: version control seemed like a good choice”

It seems like this is the main reason why you switched from SVN to Git -- hype.

dasil0032• 16 years ago

Yes, if you ignore the first 3 real reasons.

jister2• 16 years ago

The other 3 reasons have weak arguments.

gte910h5• 16 years ago

In any team larger than 3 actively working on code, git is a far superior local client than svn. The speed of checkin, pushing, and merges are phenomenal. Even if you use svn as your backend server, git-svn is still a stupidly good local client to use and gives you a huge number of the benefits of using a pure git solution.

Now remote git repositories (akin to svn repos) do not have a good locking large binary file solution. But other than large binaries, git is very nice in comparison (You could do hg or bzr if you prefer and gain the same, although their git/svn bridges are not known to me).

philjackson• 16 years ago

It seems like this article is premature. I would like to have read about their experiences a few more months down the line when there's been a bit more real world use.

hallmark• 16 years ago

I just attended a DVCS talk today (http://worldtour.fogcreek.com/) and one simple difference between SVN and DVCSs is still fresh in my mind:

When you are pushing your changes back to trunk, how safe is that process?

In a normal SVN workflow, when you're ready to commit your changes to the central repository to which a team member has also committed changes, you'll end up running 'svn up' followed by 'svn commit.' If you have substantial code changes and you screw up the merge during 'svn up,' there's little record of your pre-update code. In the case that you accidentally select the trunk version of a changed file for the merge, your own recent code may be overwritten.

With Git/Hg/etc, you are constantly committing your changes to the VCS. And you commit before you merge your working copy with any changes pulled from the "central" repository. If you screw up the merge, the DVCS has a record of your local work-in-progress code changes.

You could argue with SVN that any sufficiently large feature transaction should be done in a branch. Then the merge back to trunk will be safe with the branch's commit history. Pragmatically speaking, however, many people - especially small teams - end up doing all of their SVN-based development simply using 'svn up' and 'svn commit.' I know I have.

The safety that comes with a detailed commit history, especially for day-to-day file merges, is one big advantage of DCVSs.

chrisaycock• 16 years ago

We moved from CVS to Git over the summer. It was a pretty easy transition (we only have seven employees) though it took some explaining about the local-vs-remote copies.

The founders originally wanted to upgrade from CVS to SVN. I pointed-out that not only would they have transactional commits in Git, but that they could recover from anyone's copy of the repository, since everyone has a local clone. That, plus the first check-in (which ran blazingly fast) ended the argument.

Switching from SVN to Git: A Startup’s Perspective

Related Stories