Overall Satisfaction with Apache Subversion
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).
- 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.
- 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.
- Improved time to market for our software releases - merging code from multiple developers and finding the conflicts faster really helps.
- Added visibility into all changes in the project. Provided the developer adds some notes on each check-in you will be able to tell the history of features added to the project in time.
- Allowed us to do collaborative work on the same source code. Previously we were using Visual Source Safe which was not providing this.
We used Visual SourceSafe before SVN many years ago and we chose SVN at that time mainly because it allowed us to do collaborative work on the same source code. It also had improved conflict resolution when doing code merges, blaming changes etc, which improved the speed of doing releases and overall the team's happiness. However, now we are moving our software projects to Git with Bitbucket due to various reasons: flexibility for developers in working with branches, support for code reviews, pull requests etc.
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.