Skip to main content
TrustRadius
Apache Subversion

Apache Subversion

Overview

What is Apache Subversion?

Apache Subversion is a version control option that is free to download and open source under the Apache 2.0 license.

Read more
Recent Reviews

TrustRadius Insights

Apache Subversion is widely used by various teams and organizations for version control and code management. One common use case is in web …
Continue reading

Git >>>>>>> Subversion

7 out of 10
January 19, 2015
Subversion used to be our main version control software before we started using GitHub. But after introduction of Git, we stopped using …
Continue reading
Read all reviews
Return to navigation

Pricing

View all pricing
N/A
Unavailable

What is Apache Subversion?

Apache Subversion is a version control option that is free to download and open source under the Apache 2.0 license.

Entry-level set up fee?

  • No setup fee

Offerings

  • Free Trial
  • Free/Freemium Version
  • Premium Consulting/Integration Services

Would you like us to let the vendor know that you want pricing?

9 people also want pricing

Alternatives Pricing

What is GitLab?

GitLab DevSecOps platform enables software innovation by aiming to empower development, security, and operations teams to build better software, faster. With GitLab, teams can create, deliver, and manage code quickly and continuously instead of managing disparate tools and scripts. GitLab helps…

What is AWS CodeCommit?

AWS CodeCommit is a fully-managed source control service that hosts secure Git-based repositories. It is designed to make it easy for teams to collaborate on code in a secure and highly scalable ecosystem.

Return to navigation

Product Details

What is Apache Subversion?

Apache Subversion is a version control option that is free to download and open source under the Apache 2.0 license.

Apache Subversion was designed to be a full featured and better version of CVS. Its features include:

  • Most CVS features - CVS is a relatively basic version control system. For the most part, Subversion has matched or exceeded CVS's feature set where those features continue to apply in Subversion's particular design.
  • Directories are versioned - Subversion versions directories as first-class objects, just like files.
  • Copying, deleting, and renaming are versioned - Copying and deleting are versioned operations. Renaming is also a versioned operation, albeit with some quirks.
  • Free-form versioned metadata ("properties") - Subversion allows arbitrary metadata ("properties") to be attached to any file or directory. These properties are key/value pairs, and are versioned just like the objects they are attached to. Subversion also provides a way to attach arbitrary key/value properties to a revision (that is, to a committed changeset). These properties are not versioned, since they attach metadata to the version-space itself, but they can be changed at any time.
  • Atomic commits - No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file, and commit's log message is attached to its revision, not stored redundantly in all the files affected by that commit.
  • Branching and tagging are cheap (constant time) operations - Branches and tags are both implemented in terms of an underlying "copy" operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it's a branch as well. (This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.)
  • Merge tracking. - Subversion 1.5 introduces merge tracking: automated assistance with managing the flow of changes between lines of development, and with the merging of branches back into their sources. The 1.5 release of merge tracking has basic support for common scenarios.
  • File locking - Subversion supports (but does not require) locking files so that users can be warned when multiple people try to edit the same file. A file can be marked as requiring a lock before being edited, in which case Subversion will present the file in read-only mode until a lock is acquired.
  • Symbolic links can be versioned - Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies.
  • Executable flag is preserved - Subversion notices when a file is executable, and if that file is placed into version control, its executability will be preserved when it it checked out to other locations. (The mechanism Subversion uses to remember this is simply versioned properties, so executability can be manually edited when necessary, even from a client that does not acknowledge the file's executability, e.g., when having the wrong extension under Microsoft Windows).
  • Apache network server option, with WebDAV/DeltaV protocol - Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and allows certain features (such as authentication, wire compression) to be provided in a way that is already familiar to administrators
  • Standalone server option (svnserve) - Subversion offers a standalone server option using a custom protocol, since not everyone wants to run an Apache HTTPD server. The standalone server can run as an inetd service or in daemon mode, and offers the same level of authentication and authorization functionality as the HTTPD-based server. The standalone server can also be tunnelled over ssh.
  • Parseable output - All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority.
  • Localized messages - Subversion uses gettext() to display translated error, informational, and help messages, based on current locale settings.
  • Interactive conflict resolution - The Subversion command-line client (svn) offers various ways to resolve conflicting changes, include interactive resolution prompting. This mechanism is also made available via APIs, so that other clients (such as graphical clients) can offer interactive conflict resolution appropriate to their interfaces.
  • Repository read-only mirroring - Subversion supplies a utility, svnsync for synchronizing (via either push or pull) a read-only slave repository with a master repository.
  • Write-through proxy over WebDAV - Subversion 1.5 introduces a write-through proxy feature that allows slave repositories (see read-only mirroring) to handle all read operations themselves while passing write operations through to the master. This feature is only available with the Apache HTTPD (WebDAV) server option.
  • Natively client/server, layered library design with clean APIs - Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications.
  • Binary files handled efficiently - Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.
  • Costs are proportional to change size, not data size - In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place.
  • Bindings to programming languages - The Subversion APIs come with bindings for many programming languages, such as Python, Perl, Java, and Ruby. (Subversion itself is written in C.)
  • Changelists - Subversion 1.5 introduces changelists, which allows a user to put modified files into named groups on the client side, and then commit by specifying a particular group. For those who work on logically separate changesets simultaneously in the same directory tree, changelists can help keep things organized.

Apache Subversion Technical Details

Deployment TypesOn-premise
Operating SystemsWindows, Linux, Mac
Mobile ApplicationNo
Return to navigation

Comparisons

View all alternatives
Return to navigation

Reviews and Ratings

(56)

Community Insights

TrustRadius Insights are summaries of user sentiment data from TrustRadius reviews and, when necessary, 3rd-party data sources. Have feedback on this content? Let us know!

Apache Subversion is widely used by various teams and organizations for version control and code management. One common use case is in web development, where it serves as a reliable system to track code changes and maintain a centralized repository for shared code. According to users, Apache Subversion is highly effective in providing revision control and the ability to track commits, making it an essential tool in software projects.

One of the standout features of Apache Subversion is its interactive conflict resolution, which greatly aids in resolving conflicts during collaboration. This feature has been praised by users for its ability to streamline the process of merging changes made by multiple team members. Additionally, Apache Subversion is commonly employed to manage multiple releases in parallel, ensuring that old code doesn't inadvertently get included with new releases.

The integration with issue tracking systems like Redmine further enhances the usefulness of Apache Subversion. By associating issues with their respective commits, developers can easily keep track of bug fixes and other changes related to specific tasks or problems. This integration facilitates efficient collaboration within teams and improves overall project management.

At the academic level, many computer-related courses make Apache Subversion a mandatory tool for version control. Students benefit from using the system to track code revisions and collaborate on group projects. Similarly, in organizational settings, Apache Subversion is chosen by software departments across multiple countries to facilitate collaboration on large-scale projects. As a collective tool for version tracking and code management, Apache Subversion ensures that revisions are properly tracked by development teams.

Overall, Apache Subversion offers a powerful solution for managing source code, enabling parallel changes and the ability to revert back if necessary. It has become an indispensable tool used by various teams and organizations for effective code management and collaboration.

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.

Less flexibility compared to Git: Some users have found Apache Subversion to be less flexible compared to Git, which is the preferred choice for distributed development and provides more flexibility for software developers and teams.

Performance of SVN pulls and commits: The performance of SVN pulls and commits is not considered a strength by some users. They have experienced slower checkout, update, and commit speeds, especially on Windows.

Lack of third-party tools for code visualization: Users have expressed dissatisfaction with the lack of third-party tools available to visualize commits for a codebase, particularly across branches. This limitation can hinder their ability to track changes effectively.

Based on user reviews, there are three common recommendations for this software:

  1. Try the software for group QAs of living documents, especially if tracking history is important. It provides end-to-end visibility of each commit and makes it easy to track delta changes.

  2. Consider the integration with Intellij. Many users find it convenient and user-friendly.

  3. Utilize version control features and code maintenance capabilities. Users appreciate features like color coding and find it effortless to manage version control using SVN. It helps maintain code stability and ensures that test code is not left in deployments.

These recommendations emphasize the software's strengths in facilitating collaborative document review, its integration with Intellij, and its robust version control and code maintenance capabilities.

Attribute Ratings

Reviews

(1-5 of 5)
Companies can't remove reviews or game the system. Here's why
Richard Davies | TrustRadius Reviewer
Score 5 out of 10
Vetted Review
Verified User
Incentivized
Our web development team uses Apache Subversion as one of our version control systems. A version control system is a critical tool for software development because it provides a central repository for our shared code and also tracks how our code changes over time, allowing us to view a history of changes or revert back to a previous version if necessary.
  • Retain a history of changes to a set of files
  • Allow multiple people to collaborate on a set of files and merge changes together
  • Apache Subversion works great when all users have access to the central Subversion server. This might mean users need to be on the same network.
  • Apache Subversion isn't great for "offline" work as it requires access to the central Subversion server.
It's a relatively simple version control system so it works great for an individual or small team (less than 10 people). But if you have a medium to large team, especially one with members distributed over a large geographic area, or one where individuals need to be able to work "offline" without access to a central server, Apache Subversion will likely not be the best choice.

Also, if you're maintaining an open-source project where outside people will be interacting with your code repository, git is probably a better choice because it's becoming the de-facto standard these days and what most developers are familiar with.
  • Free
  • Version control and history
  • Non-locking collaboration model
  • Windows Server compatibility (VisualSVN)
  • Apache Subversion was easy to install and configure, and requires little maintenance.
  • We have had a few instances where the code repository has become corrupted and repairing this situation requires significant time and is frustrating.
  • It has a relatively easy learning curve so new users require little training and can be productive very early.
  • GitHub and Visual SourceSafe (Discontinued)
After Microsoft Visual SourceSafe was discontinued, we chose Subversion and it was a great choice. We were able to migrate to Apache Subversion very quickly and easily and benefited immediately from its non-locking workflow (SourceSafe required users to "lock" the file when editing to prevent editing conflicts from other users, whereas Subversion allows multiple users to edit the same file simultaneously and then merge conflicts later.)

While we still use Apache Subversion for our legacy projects, we've migrated to Git and GitHub for our new projects as that is the new "cool kid" and it provides some benefits such as distributed and offline development. But Git is more complex than Apache Subversion and not as easy to learn.
April 08, 2021

SVN Apache-Report

Rob Domenico | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User
Incentivized
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.
  • Easy install
  • Integrates into agile project standards
  • Revision regressions tracking in projects
  • Requirements more straight forward (CVS editing options)
  • Some packaged dependencies are unnecessary
  • Potential for vendor packaged security issues
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.
  • Thus far the ROI has been a positive investment in time and tooling
  • Less requirements for small teams is also a positive
  • No real negatives for our team
Apache Subversion has been the go-to for our project with SVN client Tortoise (from sourceforge).
Cristian Bodnarasec | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User
Incentivized
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.
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.
  • 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.
Arthur Adams | TrustRadius Reviewer
Score 9 out of 10
Vetted Review
Verified User
Incentivized
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.
  • 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.
  • 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.
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.
  • It allowed us to deliver the right files to our customer without "clobbering" previous releases, making for a far more satisfied customer.
  • It allowed our developers to work on two releases in parallel (plus an occasional third, for emergency fixes).
  • With some simple hooks, it allowed us to set up a system where code was was automatically deployed to test servers as soon as developers committed it, making testing easier. This was made easier by virtue of being a ColdFusion project, which requires no compilation. However, that is possible for compiled code with a continuous integration system like Jenkins.
Git is probably the biggest open source rival to Subversion. It's designed for distributed development, an environment I'm not very familiar with. I've only got some experience with it, and only as a user, and even that is limited. I had some trouble wrapping my mind around the model, until I had a moment like a cartoon light bulb going on over my head when I realize "every developer has a private branch!" That's not 100% accurate but it's a nice way to look at it. It also doesn't require (but still can use) a centralized server, which can be nice for small projects. It's my understanding merging is much easier. I have no experience with Mercurial but I understand it's very similar to Git. ClearCase is a bloated mess, difficult to use and administer. It's also VERY expensive. I'd only even consider it for a massive enterprise level project.
venkat nitin panaganti | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User
Incentivized
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.
  • 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.
  • 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.
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.
  • I cannot speak on ROI but Apache Subversion is definitely the best version control tool for a project of any size. It serves the user's purpose in a complete satisfactory way.
  • As it is open source, there is no need to spend any amount on it, which makes it an even more easier choice.
  • The most negative impact Apache Subversion can have on you is that you will not want to use any other version control tool after using it.
Git is a newer version control system compared to that of svn. I think that svn is more stable, easy to learn/use, and not-so-complex as Git. Also, svn has very good client applications which provide extremely user-friendly user interfaces. Apache Subversion is also open source which makes it an even more eligible to use as there is no investment at all.
Return to navigation