TrustRadius Insights for Apache Subversion are summaries of user sentiment data from TrustRadius reviews and, when necessary, third party data sources.
Pros
Stability: Many users have praised Apache Subversion for its stability, with some mentioning that they have experienced almost zero downtime over several years of usage. This reliability has made it a preferred choice compared to newer version control systems.
End-to-End Visibility: Reviewers appreciate the end-to-end visibility of all changes in the project provided by Subversion. This feature allows for effective revision control and makes it easier to track down and resolve conflicts.
Integration and Extensibility: Several users have mentioned that Subversion's integration with tools like Redmine and its ability to be extended using scripting languages like Perl are valuable features. These integrations enhance productivity and simplify workflow management.
Used mainly as a collective tool for version tracking to ensure revisions are tracked by the dev team, and all maintain branches of our team/project repositories. To commit the revisions once all devs have merged code from respective timelines.
Pros
Easy install
Integrates into agile project standards
Revision regressions tracking in projects
Cons
Requirements more straight forward (CVS editing options)
Some packaged dependencies are unnecessary
Potential for vendor packaged security issues
Likelihood to Recommend
Can be [suited] for teams building solutions and manage code file versioning. Subversion for us simplifies the changes per file and code version before merging to branch for continuous integration and eventually deployment. With Apache Subversion in the process of our agile development, we can continue to automate deployment as much as possible with versioning.
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.
Subversion is being used by our engineering team to manage the development code we write for the company.
Pros
Can be used from many locations, like a cloud-based system but with more custom control--and its free!
Multiple projects easily stored in a single repository, which aids in maintenance of common code, yet also easily allows for separate repositories where no sharing is desired.
Very stable, with lots of additional tools to help maintain and examine repositories (e.g. websvn).
Much easier to understand when coming from more traditional SCM systems like CVS and Perforce (as opposed to Git, which is a bit of a paradigm shift).
Cons
Refactoring the layout of a respoitory--or a part of a repository--can be a bit painful, especially for users with workspaces associated with the affected part of the repository. Not sure what could be done to make that better, but it would be nice if something was possible.
Folks coming from Git can have problems using Subversion. Again, not sure anything can (or should) be done to address that, but it is occasionally an issue.
Likelihood to Recommend
Where multiple developers have well-defined areas of responsibility it works great! When many developers are all working in the same area of code, so changes overlap, then it is more of a challenge. But, like Git, it has pretty good merge tools to help resolve conflicts.
VU
Verified User
Engineer in Engineering (E-Learning company, 51-200 employees)
In my organization, Apache Subversion (SVN) is used as a versioning software for some specific types of objects. It is always and only used to allow the multiple processing of objects avoiding that a resource overwrites more recent changes and to keep track of the last changes made so as to go back to the previous modification and evaluate the differences.
Pros
Software versioning
Very stable product
Easy to use
Cons
The installation requires some initial configuration
Improved interface
Inconvenient update management
Likelihood to Recommend
If you have multiple development environments and different resources involved; if you have more developers accessing the same files and the changes are continuous (for example if you are in a continuous delivery condition) it is certainly advisable to implement a versioning solution and SVN is a good product certainly.
We used Subversion to manage a ColdFusion based software development project for a US Federal government contract. We were largely isolated (both geographically and organizationally) from the rest of the company (it was their attempt to get into Federal contracting) and I'm not sure what was used in other parts.
Our biggest reason for using it was to allow working on multiple releases in parallel. Before I helped set up Subversion properly, they were delivering old code with new releases, "clobbering", as they said, previously delivered code. By setting up proper branching, I fixed the problem, to the relief of both the company and the customer.
I also integrated it with the Redmine issue tracking system, requiring developers to associate issues with their commits.
Pros
Version control - it's what it's designed for.
Modifiable - It only takes a little bit of knowledge of a scripting language (I used Windows BAT files calling Perl scripts) to extend capabilities, like the aforementioned integration with Redmine.
Back end administration- It's a breeze. There's very little work involved in terms of administering it once you've got it installed on a server, and even setting that up isn't bad.
Cons
Distributed development - I've never worked in an environment where distributed development (developers widely scattered geographically) was a factor, but that's why git exists.
Merging - Merging of code from one branch to another can be painful, especially if it's not done frequently. (On the other hand, doing merges is one of the reasons I get a nice salary, so I can't complain too much!)
Acceptance - Let's face it, git is what "all the cool kids are using." If you've got a bunch of developers fresh out of school, they'll probably know git and not Subversion.
Likelihood to Recommend
I'd recommend Subversion for almost any software development effort. It is less appropriate for any project with widely geographically distributed developers. For VERY elaborate projects, a higher end commercial tool might be warranted.
I have used apache subversion for a course that I have taken and also for a company that I intern for. It is used for collaborating projects with team members. At the university level, apache subversion is a mandatory version control [solution] to be used in many courses and an option in many other courses in the fields related to computers. At an organizational level, at the company that I currently intern for, apache subversion is used by the whole software department over 3 different countries to collaborate over the huge project we are working on. Apache Subversion is a simple tool used to keep all the people working on a project on the same page by letting everybody work on the same project at the same time.
Pros
Old is gold. Apache Subversion has existed before many other version control systems, including Git. It's old, stable, and easy to use with not many complications.
Excellent versioning system. You can jump between any particular version of your project to any other version just by reverting or updating, you can also create patches of your own changes and then apply the patch on your own system on a different check out or on someone else's computer who has a checkout copy.
You can search for any older commit by using words used in the comment log or by using an exact commit number or anything in between. You can also check the log of each and every individual file instead of the whole checkout.
Tortoise SVN is a client for Apache Subversion. It has one of the best UIs I have ever seen for a version control system.
Cons
Merge conflicts is one area where I think that Apace Subversion can improve a lot in. Where there is a single file being edited by two different people and the person who tries to update after someone before him commits with changes on the same file then Subversion tries to merge the changes and create an ideal file but fails miserably.
Any file renames or deletion or additions have to be specifically made through Apache Subversion or has to be notified to Apache Subversion in a round about fashion or it will be disregarded while committing the changes. While this is reasonable, it is quite annoying until a user gets used to it.
Faster on Linux and slower on Windows. Apache Subversion can be improved by increasing its checkout, update and commit speeds on Windows.
Likelihood to Recommend
I would recommend using Apache subversion for any kind of project no matter the size or type of the project. It is very well suited in scenarios where the project is being worked upon by a team, especially a large team operating over various time zones. It provides a good means of collaboration among team members, allowing them to work peacefully and time effectively. I do not recommend using apache subversion for projects that are solely documentation based because it would be an overkill. Instead you could use Google Drive for such projects.