Svn doesn’t last long
Svn was designed with the inherent assumption that the context of a developer within any single codebase would be linear, but as a team scales, bugs arise and features are added to a product, that assumption quickly falls apart. Developers need to have the ability to constantly switch between fixing bugs and working on features. Developers while working in SVN would simply commit the changes they make before switching to working on something else. Eventually the repository would have incomplete and unstable codes, quickly spiraling out of control.
The real problem starts when other developers get the unstable code and they start working with it.
Stable and Development branches will help improve this situation. Although subversion’s branching helps quite bit, over a period of time it too deteriorates. So to bring back sanity Locks are introduced and just like threads developers too enter deadlocks and everything just falls apart.
Git specifically designed to solve this problem. Git branching is so powerful yet so cheap that it becomes difficult not to use it and branching is well complemented with Git’s superb merging feature.
Switching context is quite easy with Git, just create / switch to a branch and continue working, and when the work is done just merge them back into the central master branch.
Git is a distributed version control system, so unlike svn creating a branch does not make it available to other people.
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.
Git isn’t without problems though, Git has a complex branching and merging model, Git commit tree structure is hard to understand, DVCS concepts are difficult to comprehend etc.
Svn has many well built GUIs, which makes it easy for beginners to pick it up, Git on the other hand does not have any GUI that matches the quality of GUIs built for Svn. The command line interface for git isn’t easy to use for first timers and svn migrants. People who are used to Svn GUIs would especially find it difficult to it.
Git’s branching and merging though very powerful, flexible and useful, is quite difficult to comprehend unless the person has burnt their hands at a central version control system.
The branching and merging works well because commits are a collection of patches on a tree structure, which by its own definition needs a lot of support for people to understand.
Finally the concepts that commits are local and that they need to be dumped to the remote repository by copying it, leads to a lot of questions and confusions, especially to people who are damaged by central version control systems.
The migration process is surprisingly simple, just clone the svn repository with git-svn and push it to a git repository. Cloning the svn repository may take a long time though. Our repository with over 11k commits took 40 minutes to clone, while pushing the same to a git repository took only 2 minutes.
Our Github workflow is very similar to any open-source project on Github. Every team member forks a private organisation repository. They commit and push their changes to their forks and send in pull requests when code becomes stable. Issues are maintained on the central github repository and can only be closed by commit messages and accepting pull requests.
The central github repository has 2 branches, master and production, new features and bug-fixes are sent as pull requests to the master branch of the central repo. The production branch contains the most recently deployed code. Pull requests sent to the production branch are patches that need to be urgently fixed.
The reason that master and production branches exist is because testing and deployment are currently quite time consuming.
Looking ahead
The migration to git initially reduced the productivity of the team but it has drastically reduced mistakes and improved traceability of code changes. We are working towards reducing the time it takes to test and deploy code, once that is achieved we would easily be able to move a single branch workflow.
Discuss on HN https://news.ycombinator.com/item?id=6487567
The post GIT vs SVN – The real reason to move away from SVN appeared first on .