Source code versioning made simpler
Rating: 8 out of 10
IncentivizedUse Cases and Deployment Scope
We used to use Apache SVN for source code file versioning for all our software projects in the e-business department. Now we only use it for few projects that are not transitioned yet to Git. SVN, as most of the file versioning tools provide the following for us:
- Revision control.
- Interactive conflict resolution.
- Tracking commits.
- Collaborative commits (with the ability to lock files for disabling collaboration and avoid conflicts).
Pros
- Revision control done properly - you have end to end visibility of all changes in the project.
- Conflict resolution - visually highlighting the differences helps to track down the problem.
- Being open source and very popular.
- We are using SVN hosted in our network - it is very stable, we had almost zero downtime in 4 years.
- Rollbacks are made simple and easy to use.
Cons
- It is missing the pull request feature which Git has. You can still do it in SVN but more work is needed.
- It is centralized. Nowadays software developers and teams need more flexibility and will choose Git for that.
- Performance is not a strength of SVN pulls and commits.
- The disk space use by working copies is almost double due to the way SVN organizes its working files.
- Less support for .NET developers since it comes from the open source world.
- Code reviews could be made simpler to help the reviewer more.
Likelihood to Recommend
Subversion solves our software versioning problem by providing tools for conflict resolution when doing collaborative work on the same files and projects. We use it with TortoiseSVN and it works great for some of our projects with smaller teams. However, we have a need to make code reviews more and it is a little more difficult to do that in SVN, compared to Bitbucket and Git.