
Ask HN: Why and from/to what VCS did you switch? - sebazzz
I&#x27;m wondering who of you switched source control systems, from and to what version control system you switched, and how you convinced your team&#x2F;company? What is the size of your team? Did you convert (all) of your history? What pros&#x2F;cons were the deciding factors?<p>About 7 years ago we switched from CVS to SVN. Primarily reasons were tooling quality and the limitations of CVS (not being able to remove folders for instance).<p>Currently we are considering switching from Subversion to Git. The reasons are, again, tooling (Visual Studio + Code Lens, TeamCity feature branches, nice server software in the form of Gitlab), better merging than SVN, and better client features like stashing. We also like to employ forking in some software implementations.<p>I love to hear what your stories are.
======
cimmanom
I switched from SVN to Git in 2012 (after briefly sampling Mercurial). Git is
so much better than SVN for collaboration it's indescribable.

Git can be intimidating at first. I recommend reading Git From The Bottom Up
before making the change, and encouraging the rest of your team to read it
too. It'll give you an understanding of how your code and commits are actually
being represented in the repository and what's actually happening behind the
scenes when you issue those seemingly magical commands.

Also get a good GUI tool that will let you visualize repository history, which
is more important when you start adding more branches. There are a lot of
options out there. Also helpful is the ability to pull up such a visualization
on the command line (Google for "git lg").

Git is so much better than SVN for branching, collaboration, and
experimentation that I could write a book about it (and I'm pretty sure a
couple people have).

Expect a temporary slowdown during the learning curve phase. Equip everyone
with a cheat sheet for the most common commands. For designers and copy
writers who do HMTL/CSS development and don't understand the command line or
need to understand the Git internals, there are some dead simple GUIs
(Github's desktop client and a handful of others) that they can use
comfortably.

Git is a bit more powerful than SVN, and that allows users to get their
working copies into unexpected states more easily than SVN, but also makes
recovery from those states easier for someone who knows what they're doing.
Designate a couple people to learn Git well enough to explain things to others
and fix branch problems (learning things like cherry-picking, reset, etc). Set
a few rules (never push with a "\--force" unless you're one of the designated
fixers fixing a problem; never rebase something that's already been pushed).

One of the best things Git does is that by making branching and merging cheap
and lightweight it can facilitate agile practices like more frequent smaller
deploys and allow people to make local branches off a feature branch to
explore different approaches to a problem. Once everyone is comfortable using
the VCS, you can start exploring the possibilities.

------
eesmith
You might like
[https://www.python.org/dev/peps/pep-0481/](https://www.python.org/dev/peps/pep-0481/)
, which describes the reasons that CPython development moved from Mercurial to
Git.

Also note the line "This particular PEP is offered as an alternative to PEP
474 and PEP 462 which aims to achieve the same overall benefits but restricts
itself to tools that support Mercurial and are completely Open Source."

