3 ms·
Ask HN: Why and from/to what VCS did you switch?
I'm wondering who of you switched source control systems, from and to what version control system you switched, and how you convinced your team/company? What is the size of your team? Did you convert (all) of your history? What pros/cons were the deciding factors?
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).
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.
I love to hear what your stories are.
- eesmith 9y agoYou 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."
- cimmanom 9y agoI 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.