

Why opting for Git was a natural choice - mataug
http://kissflow.com/kissu_kissu/git-vs-svn/

======
millstone
I think this article does not do the svn workflow justice.

 _Svn was designed with the inherent assumption that the context of a
developer within any single codebase would be linear_

This may be how the engineers in question used svn, but that's certainly not
how svn was designed!

Creating a branch in Subversion is not difficult or expensive. It's natural
for each engineer on a team to have a separate svn directory containing
"private" branches. If engineers are committing unstable code to the trunk,
they're doing it wrong.

 _Git branching is also cheap and quick, unlike svn in which a branching
creating a new copy of code. Git also preserves history when branching, unlike
Svn._

Subversion uses copy-on-write when creating a branch, so it is not expensive.
Subversion also records the branch event in the file's history.

It sounds like the team had a flawed understanding of svn, and was using a
terrible workflow. The benefits of the switch are not due to git, but to
investing actual time learning a scm tool. That same time invested into
learning svn would have paid equal dividends.

~~~
taspeotis
> Subversion uses copy-on-write when creating a branch, so it is not expensive

It doesn't matter what the server does, it's relatively slow on the client to
either switch to or checkout a branch.

~~~
millstone
With git, you typically have a single checkout of the repo. But with svn, it's
natural to have separate checkouts of each branch you care about, in separate
directories. So a typical "switch" in svn is not a switch at all: you just
start working on files in a separate directory, or even simultaneously on two
separate checkouts (which is more awkward in git).

I use and like git, but multiple checkouts is one aspect of the svn workflow
that I miss.

~~~
taspeotis
You're making my point for me. In typical Subversion client usage the server's
CoW optimisations mean nothing.

If you have to check out each branch you make, using Subversion gets really
slow, really quickly.

------
mataug
The gist: The technicalities of moving away from SVN was never a problem for
us, It was more of a workflow issue.

I think this should be the real reason anyone should consider moving their
codebase from SVN to GIT.

------
tehwalrus
The way I handled branching in SVN was to have several checkouts of the same
trunk, and run "svn update" to fast-forward before committing (once my patch
had passed code review.) Hard drives are cheap, brain cells expensive!

(note, this model works fine when you have a big company machine sat in an
office on gigabit LAN to the SVN server - break any of the assumptions there,
and SVN quickly deteriorates. I'm not saying git isn't better, just than SVN
isn't that bad where I encountered it.)

~~~
Peaker
Hard drives are slow. Copying a huge working tree to make a small branch makes
no sense.

~~~
tehwalrus
I would just permanently maintain 4 or 5 checkouts of active projects, and
rename the containing directories for branch names. I know git is better, I'm
just saying SVN can be used in a similar way, if less efficiently.

------
sircausticsoda
Git sucks. It ruins my process. SVN has great integration with eclipse .

~~~
roryokane
It would be more accurate to phrase that not as “Git sucks”, but as “the EGit
plugin sucks”, or, if you must generalize, “Git’s ecosystem sucks”.

~~~
mataug
I would agree, There is nothing that can beat the Git-cli at least for now.

~~~
chrismonsanto
magit ([https://github.com/magit/magit](https://github.com/magit/magit)) is
unequivocally better than the Git CLI if you use Emacs.

