

Switching from SVN to Git: A Startup’s Perspective - jgershen
http://www.gazehawk.com/blog/switching-from-svn-to-git-a-startups-perspective/

======
dasil003
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.

~~~
bkrausz
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
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.

~~~
freakwit
I'm sorry, if you're competent you can make svn work.

~~~
loewenskind
But if you're really good you might not be willing to spend a big chunk of
your day fighting with obsolete technologies. Unless the money makes up for it
of course.

~~~
gte910h
<http://www.kernel.org/pub/software/scm/git/docs/git-svn.html> < Doesn't
require much fighting at all.

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

------
spudlyo
_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
Advantage of Git: if your central repository fails, you can recover from any
developer's repository.

~~~
bluesnowmonkey
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.

------
ojbyrne
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
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>

~~~
alinajaf
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.

~~~
ximeng
Agree on 'cave-hiding' being just as possible in svn as git, but I disagree
that your workflow is particularly complicated or poorly performing in svn.

Creating branches in svn is cheap, switching branches is cheap, checking out a
new working copy if you want to work on two changes at once is also cheap,
merging is cheap. There's no reason not to do what you're suggesting in svn.

One of the things that git does better than svn is merging branches when files
have moved, but I don't think your use case addresses this directly. Git does
some things better than svn, but svn does a good enough job that you have to
be a little careful when making the case against it.

~~~
alinajaf
> Creating branches in svn is cheap, switching branches is cheap, checking out
> a new working copy if you want to work on two changes at once is also cheap,
> merging is cheap.

I think then the problem is our definitions of 'cheap'.

A typical switch command on a working copy of our codebase at work (20,000 +
files) takes 1-2 minutes, and its a lot longer for creating a new branch. In a
git version of the same repository both these operations are comparatively
instantaneous. YMMV.

Also, regarding merging, I believe that in new versions of the svn client
there is mergeinfo, however older repositories without this metadata will give
you issues when you for example create a branch, merge changes from trunk into
your branch and then subsequently attempt to merge that branch back into
trunk.

This is the classic 'svn sucks at merging' problem and to me, its complexity
overhead that would deter me from branching, i.e. not 'cheap'. I normally get
around this by remembering the revision number of the last 'rebase' from trunk
(or give it an easily greppable commit message) and then when I do the merge
back into trunk I specify that I only want changes from the last rebase to
HEAD.

The internal model of git makes this a non-issue, i.e. each commit has a
parent commit, and for any given commit on two separate branches, git just
walks the tree up to the nearest common ancestor.

~~~
ximeng
Any version from 1.5, which was released in June 2008, has merge tracking. If
you're using svn and don't understand how mergeinfo works, then you're not in
a position to make a fair comparison on merging. A lot of the comparisons
between svn and git/hg/etc. are made by people who don't seem to understand
recent versions of svn well.

Yes, old versions of svn "suck at merging", but the workflows with merges
between multiple branches you describe work well in modern versions of svn
with merge tracking. Your "remembering the revision number of the last
'rebase'" is unnecessary in modern svn.

I grant you that switch can take a while on a large code base, as can a
checkout of a new working copy. Creating a new branch is contrary to what you
say instantaneous in svn due to the cheap copies, however getting that new
branch in a new working copy to work on I admit might take a while. A large
part of this problem is mitigated if you just have multiple working copies
checked out, but not all.

The details on why branching is cheap in svn are described here:

[http://svn.apache.org/repos/asf/subversion/trunk/notes/subve...](http://svn.apache.org/repos/asf/subversion/trunk/notes/subversion-
design.html#server.fs.struct.bubble-up)

Part of the problem with svn is that the model is too flexible compared to
git: the merge tracking supports tracking partial merges between branches,
which is arguably an unnecessary complexity - the svn developers have
expressed concern about whether this feature is valuable given the complexity
it adds.

For general merge scenarios if you're using mergeinfo correctly, follow the
practices laid out in the svn book, you shouldn't find merging particularly
difficult or expensive in svn, even if you're doing relatively complicated
workflows.

I'm not saying this is easier or works better than svn than git, just that
it's doable and not as bad as many people make out. The merging in svn is
(too) complex, but once you figure out how it works then it works well. With
your "I believe...there is mergeinfo" and loewenskind's "I've done it. Once."
I get the impression that neither of you have put the time in to really figure
out how it works, but are still arguing against it.

Personally I prefer the way git works. But as someone who uses it everyday,
for scenarios like the ones you say are nightmares, I don't think svn is as
bad as you make out. There is an argument to be made for using git, but
neither you, loewenskind nor the article make it as well as you could.

------
jister
“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.

~~~
dasil003
Yes, if you ignore the first 3 real reasons.

~~~
jister
The other 3 reasons have weak arguments.

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

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

