Subversion Reviews & Product Details

Diffing changes against the repository and being able to run blame to see who changed what lines. We don't use it for rolling back revisions very much, but that possibility is very nice as well.

Sometimes the folder permissions get messed up and the icons don't show correctly. Also the SVN web server we're using is called uberSVN and it sometimes gets hung up and I have to restart things before we can commit.

Just start using it. You won't believe how much it will change your life when you do. If you are doing any kind of code that needs maintenance, SVN will help you keep track of what you did when and why you did it. It also helps to make sure you don't accidentally leave test code in when you deploy.

Keeps code among multiple developers organized. Benefits are organization and less code merging.

1. This tool gives you power to work collaboratively. And this collaboration will happen with out impacting anyone's work.

2. It points out changes between existing code and uploaded code then and there.

3. Shows difference while merging code in trunk.

4. Find out old code by just providing the version number

Subversion is a free/open source version control system (VCS). That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed.

Well it is Hard to say what you can dislike in this tool unless you use it.

But if your code is placed inside zip or if it is a meta data, then this tool can't give exact changes between old code and new code.

If your end products supports text editor then go for it. It will become your best friend while checking in your code on cloud. Subversion is a free/open source version control system (VCS). That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed.

It is easy to use , reliable and smart. It can take care of your Job as a Hammer when the job become nails! For parallel Development, Collaboration this tool make code comparison easy.

it tracks and provide end to end visibilty of each commit by developer.Also the hooks provide easy way for notification to be sent to IT leads whenever any change is being commit , also the delta changes can be tracked very easily.

Cleanup the locked directory takes lot more time than it should take. We need to forcefully commit executable files/binary files using in the project

it tracks and provide end to end visibilty of each commit by developer.Also the hooks provide easy way for notification to be sent to IT leads whenever any change is being commit , also the delta changes can be tracked very easily. It is easy to learn for new members within the team and provide end to end usage in terms of development cycle

it is used for source code management , version control and scripts repository

Subversion has been around for 17 years. It remains very popular despite social code being all the rage with the kids today. SVN and GIT are nearly on par with GIT slightly edging SVN out. I use hosted svn as a service. I've had zero down time, zero server problems and only good experiences with SVN. SVN also, to my brain, is a more obvious, pragmatic technology. Simple terminology, simple tools.

I do like the idea of giving people access to a codebase they can change without overwriting my code (like GIT). SVN does not allow for "pull requests" like GIT. I also dislike the stigma that surrounds using SVN instead of GIT. It's like I'm a leper.

Don't let the stigma of using SVN over GIT sway you - choose the best tool for the job based on your own requirements.

We have a large codebase for a fintech business located in a SVN repository with > 10000 commits. Source control is the only way to organize a project like this. The benefits are obvious vs running without. We have custom built tools for releasing code to production that integrates automatically with SVN and an internal ticketing tool.

Tortoise svn is the best source code repository tool. Download and upload speed of data and Ability to customise svn is excellent. The most important is its ability to integrate with any platform. Committing code, Logs and Conflict resolving is great in svn. This tool allows many user works on the same filer at same time. Tool is also very configurable.

Clean up command takes time and needs some imrovement. Svn native compare tool also needs to be better.

Source code repository

Tracks a whole commit which makes it easier for a developer to keep track/check the history.

Overall revision number makes build versioning and regression testing much easier:

Prevents accidental committing of conflicted files.

Offline diffs and availability of customs diff's.

supports versioning of binary files

working copies take up twice as much space.

recursive greps of source directories now turn up lots of bogus hits in ".svn" subdirectories

Need to forcefully commit executable files/binary files.

SVN will now not automatically cope once you've removed the conflict markers from a file. It will have marked the file as "conflicted" when it first displayed the C status, and when you've sorted it out you have to manually tell it "resolved".

SVN does not allow rollback of commit. Authors suggest copy good repository state to the end of trunk to overwrite bad commit. However bad commit itself will remain in repository.

SVN in Linux is far better than tortoise SVN available in Windows since we have to write down commands to commit the code it shows some more importance of what we try to do. I suggest people should double check before committing the code.

Mainly used for version controlling and code sharing.

I like Subversion for certain projects where I want a centralized version control system. It may not be quite as flexible as others, but it is a very mature solution that meets that particular need. Subversion's treating a checked out repository as a "working copy", rather than a repository in and of itself, provides clarity (at the expense of flexibility).

I dislike its relative inflexibility on projects where another, less centralized solution (such as Git), may be more appropriate.

It is definitely a good idea to analyze your particular needs and evaluate your options. Much of the time I've found that a more flexible, less centralized solution, such as Git.

I've had clients for whom I've set up a central storage and version control solution for their business files. They were able to access the repository as a regular file system, changes being automatically committed. This worked out great for them.

Of course, I also use Subversion on certain software development projects where centralization is preferred over collaboration and more open, open source.

Easy to use and learn with support for tags/branches, reverting, history, merging and more

It can be easy to mess up a commit or accidentally delete a versioned file/folder, especially when creating a tag/branch

We are using SVN for version control of all our software code bases. It has vastly improved our productivity and allowed us to compare versions of code to find bugs or perform code reviews

Subversion is remarkably easy to install, configure, and even self-host. The directory structure is scalable and the ability to check out individual directories of a project tree makes it very easy to separate out modular components of a project.

The centralized nature of Subversion, however, makes collaborating on features remarkably difficult. The branching feature of Subversion also makes otherwise lightweight repositories very bulky as the project grows.

The centralized nature of the repository will take anyone familiar with distributed VCS (i.e. Git or Mercurial) a while to wrap their heads around. With Subversion, there is one central repository from which all developers "check out" their code (versus "cloning" a repository to make a copy). All changes flow back upstream to the central server, which may or may not be the kind of workflow you want to embrace. If you're working on an agile (scrum) project, Subversion might not be the right fit.

I primarily use Subversion as a release management system rather than for active development. This allows me to keep a specific, auto-incrementing version number in production and progressively roll out (or roll back) changes as needed.

Subversion is the best version control system because it comes with command line options as well as GUI interface aka client and various plugins are available. One of the one client I use with Subversion is TortoiseSVN. All tasks can be accomplished with a single click, be it creating a branch, updating source tree, commit, revert or tag a revision. Also creating a patch, viewing history, or updating credentials after a password change is fairly straight forward. I have been using Subversion since more than 6 years and I like the usability. Even for new users it is pretty easy to use. I have used multiple versions and they are improving with every new release, which the part I like about Subversion.

Subversion can be challenging to use at times for ex when merging the conflicts in the files or deleting/renaming directories. I ran into issues where Subversion didn't commit deleted/renamed folders properly and if you are not careful on rename, none of the history will be carried forward if you don't use Subversion rename feature or drag/drop features if moving between directories. I end up resolving conflicts manually many time instead of using diff editor which can be very time consuming when tight deadlines are approaching or when you are merging the code from branch to another branch. Also, sometimes lock is obtained on source tree when you are trying to perform multiple operations at once and then you need to go clean up the working copy status.

Definitely recommend - it is suitable and easy to learn for new users as well for the users switching from another software. Even for experienced users, it can solve many business problems based on day to day demands to manage the source code in version control system.

The main purpose of using subversion is to do effective code management across different versions of the product and version control. Patches need to be applied, releases are created ongoing basis and tags are applied for every day needs based on business demands. Subversion makes it easy to check out source tree based on the given branch, or a tag and perform various operations. You can even filter down the history based on certain date range and that helps when you are troubleshooting an issue and want to see check-ins from certain time.

I use subversion because someone else in my organization was already running a server, and let me add some repositories to it. The standard free book on their website has a great introductory chapter or two that is all you will need from a user perspective. I don't really need any fancier features, just plain text diffs. If you're on Windows, get Tortoise-SVN for a client, also a freebie.

I dislike having to set up and run a service, but someone else in my organization manages it anyways. Although, that means we have to go through that person to make any changes. It would also be nice if it could do diffs on binary files, but it is very good at what it was meant to do, which is source code version management.

Subversion met our needs and we use it because it was already being used in our organization - find out if there is already one being hosted that you can piggy-back on.

Subversion is open source version control that allows teams to share source code or other files and maintain revisions. It lets my team maintain source code, and track releases, versions, etc., all the standard version tracking.

I like the checkin and checkout that is specifically color coded. The color coding on your local machine itself is sufficient to tell that there are pending changes yet to be checked in or the version is in sync with the server.

Sometimes, the version does not get updated with the latest one. It will make you delete the entire folder and get the latest version from sever again.

It is very easy to use. I like the color coding that it gives when the version is checked out or is sync with the server. It is easy to manage the version control using SVN.

Version control management

In our company we using Subversion everyday.

This software allows each department to work independently on different projects with different resources by tracking changes of each. It is definitely a great help to have an optimal teamwork without losing the changes of anyone.

It is easy to use and is very quick to update \ download modified projects.

The initial configuration can be difficult since it is based on Apache servers and requires a minimum of know-how.

Apart from that no objection.

Sometimes, for example by using it on the filesystem is not very clear whether the project has been updated or not because the icon does not update automatically, it is a little graphic bug but I think it depends by type of client that you are using (for example Tortoise) .

This way of working has saved us so long as it is not necessary to wait for a resource to finish their work and at the same time you can compare previous versions with the current and if you need, you can do the merge between the changes.

I like the windows integration, the history view and so on, but i love the ease of use of this software. We use Tortoise svn as the client for Subversion, and we've more or less 30 between developers, dba and the graphic team. It's fast and powerful. Excellent branch/tagging features (really cool as developers), useful of course the repo-browser. It's also cool the capability to exclude some file/directory from repository.

It should be integrated with visual studio!! for that we use Team Foundation Server, integrated in the Visual Studio IDE...Sometimes you need to do a cleanup to make everything it's ok but...it's ok, no worryes about that.Sometimes you have to do more than once update/commit/cleanup because files are somehow locked.

We use Tortoise SVN as client, and it's cool, free and not too slow. I recommend that as subversion client.

We can work together, more than 20 between dev/devops/dba/graphic on the same resource or project. Really powerful for collaboration, merge and so on. We have a continuous delivery system and we're really happy with subversion.

Subversion is a centralized revision control system that allows for fairly easy management of source code. Renamed/moved files maintain their revision history, which is nice. SVN also supports branching, which is very useful if you or a group of people are working on the same file(s) concurrently.

SVN lacks some of the features I've come to expect after using Git, such as staging part of a file and stashing local changes. It also seems to be slower than Git, although this probably varies from one repository to another. In general, I prefer distributed revision control systems over centralized ones.

Subversion does its job well and is a good choice, but I would also consider using a distributed revision control system if it's appropriate. Git is an excellent option.

We use Subversion in the research lab I work in to manage source code among several programmers. The benefits of revision control cannot be overstated in such an environment. It's great to not have to worry about unforeseen circumstances destroying work. At the end of the day I simply commit my changes and rest easy knowing they are backed up and safe.

Apache Subversion (i.e. SVN) is a very solid source control system that has been proven to be reliable and useful for years. It was launched in 2000 and is still being maintained to this day. It is an open-source piece of software so there is a lot of community support. Since it is widely used, there is a lot of support online.

There really isn't much to dislike about SVN. I guess the only thing I "dislike" is that, at least in my use, has been overtaken by git, which is a competing source control system.

If you can't use a newer source control system such as git, consider using SVN as it is a very solid choice. It is open source so works on many different platforms. There are third party GUI interfaces available for SVN too. TortoiseSVN is a great example and one worth looking at for new users.

Today, I've moved on from SVN and now use git. SVN tools and knowledge is useful for utilizing with older repositories or source control from a client's network.

Subversion is a well documented source code control software. The documentation makes it clear and easy to checkout, merge, create and merge branches, and so forth. They have even updated how branches are handled so you do not have to keep track of revision numbers. Having been forced into using subversion with no previous background it was very easy to understand, and very well documented.

Upon one of the more recent updates they changed the structure of how the subversion directories are preserved, which I liked, but it required performing an svn upgrade on all of my checked out directories. In my situation this took hours...

Among the better source code control tools out there. It is easy to use and well documented for free on their website. Before you decide, make sure you have someone capable enough to create the initial web server and setup subversion on a server with adequate protection.

Make and monitor changes to production grade compilers. It is essential to know who changed what and why within the code base, and subversion makes this possible. Using subversion simplifies the ramp up time for both those familiar with source code control and those with no previous experience.

Subversion is a development tool for managing collaborative work of several people simultaneously on the same project. How centralized server you can use the Apache Web server via the WebDAV / DeltaV protocol, or an independent server which uses a custom protocol based on TCP / IP.

There are many other software that have this feature. the competition is high, many may prefer the software "git" linux based kernel. the initial configuration requires experience in the command line level

you have to be careful when you enable access via ssh. to enable access via Secure Shell requires that the host server Secure Shell service is active. To verify that the service is present and active is useful to log in via ssh client.

currently use this software to manage shared files. each user has the option to change your files without creating problems with other users

Ease of getting started, and with multiple available GUI IDE's it works well.

Subversion can be a bit confusing on setting up multiple project repositories until you get the hang of it.

Give it a try.

Subversion allows a team of developers to work on a project while maintaining a reliable way to version releases.

makes it easy to know what went into a build

creating a branch is now a version-controlled operation, meaning you get to track who did it, when and why

"svn ls" can easily show you what branches exist and are active, which was always hard to keep track of

there is no way to bring together all the various branched versions of a single source file, if (for example) you're trying to remember which branch a particular change was made on.

it's also rather heavyweight if you only wanted to branch one single file for some unofficial or private purpose.

In my project we regularly create branches hence it is handy to use it

For me personally I like the fact that the full revision history is maintained for files that have been changed in any way. Working on various projects for various years, it's very beneficial to know who has made what change.

There are certain features like, SVN update to head vs synchronize with repository which sound almost the same. Maybe different wordings could help.

We use Subversion (svn) for all out projects. Very easy to check out projects or merge/update code.

Centralized control of SCM is important to some people. The URL scheme is easy to manage and user management with Apache integration means I rarely worry about users.

Branch management is terrible. Built-in merge isn't much better.

Basically, very few modern repositories use Subversion. Most have gone to distributed systems from centralized ones.

Are you sure you need a centralized SCM system? If you're not absolutely, legally bound to use centralized control, then you shouldn't. However, retraining a ton of people to use a new SCM tool isn't a good idea, either. The C/B analysis has to be done across your entire workforce.

We were collaborating with hundreds of developers and centralized management was necessary. Github and it's like simply weren't mature enough at the time to handle the work.

Es mucho más sencillo que Git. Te oofrece mayor libertad para usar su herramienta. Hay muchos plugins para realizar la sincronización. Si hay un conflicto con otros usuarios se resuelven fácilmente.

Alto consumo de espacio en disco. A veces, al hacer un commit te dice que no estas actualizado aunque estés trabajando solo en ese proyecto.

Mucho mejor que Git. Si vas a trabajar con otros usuarios esta es la mejor herramienta.

Versionado de los proyectos para no perder nada. Si hay que dar marcha atrás con un cambio este proceso es instantáneo.

Snapshots of where you are with code is awesome, as well as intentional tags.

I don't have much experience yet with merging code, especially when I and a coworker have modified the same file. Still a pain to figure that out.

The other alternative today is Git. I don't think there's any benefit to using one or the other, as both are free.

Source control, and also serves as a backup.

Like any version control system, I liked the ability to maintain a single copy of documentation (requirement docs, data models, etc.), rather than having 10 copies of the same document, each with a different "version" number. Subversion provides a "lock" safeguard to prevent multiple people from making updates to the same item at the same time. I found it fairly simple to be able to locate the previous version of a document.

Since you maintain a "working copy" on your desktop, I've broken the fragile link between the desktop app and the online repository. I've broken Subversion about every way possible, and learned how to manually remove the "sync" feature for the folders in my Subversion repository so that I could re-sync my folders properly. In my organization, I found that few people actually used the lock feature before making changes. I found that the merge feature wasn't as robust as I would have liked. If I'm merging a Microsoft Excel spreadsheet with another similar Microsoft Excel spreadsheet, I'd expect that to work.

Subversion was a step up from CVS, which the company used previously, but the version-control system of choice today is Git. It's built to work with the open-source community in mind, meaning it's robust enough to allow just about anyone to contribute code and make changes to the code base.

Developers were using Subversion as a code repository and were quite satisfied with it at the time. Other resources were using it for version control of documentation, and finding merge issues for Microsoft Word & Excel documents. We found that Subversion was never intended as a robust document repository.

Tracking and reverting changes is easy. For most use cases, it is adequate and easy to use.

Does not operate without access to a centralized repository, which might be a problem if you are without internet access. Working copies can get pretty big if you have several branches with a lot of changes.

There are better options for organizations of any size. There really is no reason I can think of to invest in Subversion these days.

Version control is absolutely necessary for any significant project with multiple users. Subversion gets the job done and isn't too complex or hard to approach.

Checkin/out is very simple; Handy backup of repository files;

Not able to delete revision using SUPER MODE :-), and No Cache mode to undo code, like CTRL+Z, when you accidentally overwrite the code.

we are not afraid of losing the code changes. every code change and the history is like an data asset.

for me it is the best open source that we used in the daily operation with no cost.

I really like the versioning and history SVN provides. I like the capabilities of the repo browser as well.

SVN is difficult to search in. i wish their was a way to search via search bar.

We keep our vehicle and software code/builds as well as documentation within svn.

Subversion integrates really nicely with MadCap Flare, the authoring tool that I use to write product documentation. I can count on Subversion to keep track of all of my changes and am confident in versioning.

It can be difficult to go to it through tortoise to get everything checked in when there are issues doing thing via flare integration. Branching functionality is hard to understand.

We are able to work in a fully-integrated team authoring environment. We are confident that all of our content is back up.

Good, basic version control, simple and easy to understand.

Lacks many of the features of newer version control software such as Git and Mercurial. In particular, subversion's branching & merging isn't up to par with Git.

Consider using Git or Mercurial rather than Subversion. As mentioned earlier in my review, merging in branches in Subversion is painful and is handled much, much better in Git.

This is version control for software code, helpful to track changes, revert to older revisions of code, etc.

more than 10 years we are using it. it working fine. while developing a team project its more usefully to handle the code on the server.

Continue integration is the most needed. While committing the code we face more issues on the different part.

it's not open said that.. we can't tell such a things for privacy

Having used a number of different version control systems, I would always consider Subversion for a general purpose SCM. It works very well with teams of varying skill set, where the individual developers need supervision, training and review, as may be the case with trainees, juniors, contractors and overseas developers. Centralized SCM means the leads and seniors are in control and can review work and manage processes such as CI, build, test automation and delivery. Subversion is free and open source software with a mature feature set, and a large number of client integrations and tools.

Despite claims to the contrary, multi-site configurations with Subversions are both simple to set up and robust to operate.

In Subversion, there is usually one way to do something, and to do it right. If that way is followed, the user will be blessed with success.

Subversion's strengths may turn into a weakness when a distributed SCM is required. These are more popular in teams composed of highly skilled, individually motivated contributors. The reader must decide whether this is the case. For most professional development teams the point is moot, and subversion's maturity may be the deciding factory.

This is an open source project, a number of vendors for binaries exists. Virtually every GNU/Linux distribution comes with the complete set. VisualSVN Server (free edition) is a very good start on the Windows Platform.

On the client side, TortoiseSVN is the most pooular client on Windows, and it includes a CLI. Virtually every IDE has integration and tooling.

We required centralized version control for the development of a number of commercial software projects, including integrations to bug tracking systems, continuous integration, code review and deployment. Subversion's performance is solid both on the server as well as the client side, with few developer issues.

The most important benefit was that due to it's simple usage model (one way to do things right), developer training was straightforward and cost effective.

From a single-server setup, I extended the deployment to a 3 site replicated Subversion with transparent write-through proxying for committing from anywhere and fast reads from the LAN.

Full disclosure: This review is based on my prior professional experience, and I have since become a code contributor to the Apache Subversion open source project.

Very robust, easy to use from the file explorer or an IDE. Good editor for mitigating merge conflicts

Sometimes if you don't use svn convention you may get issues like merge conflicts and temp files conflicts

Svn is a very common tool for version control, only competing software would be tortoise git which is also very good

We are using svn for agile software development and collaboration, especially with offshore employees

Sub version gets the job done. It has great versioning control and document storage. The right click functionality from the desktop is a very handy feature.

Sub version can be a little hard to navigate. There isn't a great searching feature unfortunately. The web based feature is also a little lacking

We use subversion to store documents and software code. The version management is handy. It's very easy to look up past versions of documents

It's easy to set up and use. It's doesn't have as high a learning curve like Git does. It works well for small local teams.

It also works well with all OS's, build tools (Jenkins, Maven etc) and has been very reliable.

It doesn't work as well for a big distributed team such as Git.

If you have a small local team, SVN is a good option. If you're all over the world and work different hours, Git is a better option and worth the learning curve.

Most teams are adoption Git, so SVN usage and support is dropping.

Source control. It enabled us to track our code, versions and releases to production easily.

easy to control the source code in a team in different areas

can't fetch the log of a branch few years before. I work on a program from 2012, and can't fetch the log of a branch of a project sometime.

our team is global and this a very useful tool for use to work together and cooperate easily.

SVN can handle large bin file easily.

Its help to keep track changes by other team member.

Its very simple to uses.

Its open source. Free to use.

Its not provide staging environment for per user.

Its not distributed like git or mercurial.

Its not provide hosting environment like github.

We are using svn for document versioning in CMMi Process. its help us to keep track changes done by team member. SVN can handle bin file better.

It's highly functional, and easy to use. There is little concern as far as getting it setup or working. Works great across multiple OS and environments.

It's not the fastest, easiest to integrate, or even the most versatile repository management software.

Make sure you are on the newest version available. We are currently stuck on an older version (1.6.X) and I believe a lot of the areas we suffer in are due to this. It works great for enterprise level use however, and overall gets the job done.

We currently use this to manage our companies repository. It is heavily used and handles a lot of load pretty well. Very simple to get new users setup.

Ease of use and lesser complexity than other giants like GIT

a little more flexibility to user should be provided in order to be more productive

I would definitely recommend this software for ease of use and less complexity

We have subversion repos of all our code

Our version of SVN has integrated Windows support, so unlike like git, there is no need to push and pull code through a command line interface.

There is a little bit of a learning curve when using SVN through the Windows interface, but it is still easier than git.

Use tortoiseSVN with SVN

We use this product to pull and push code to a central repository. We also use it as source control when working on code.

It can store anything easily. Easy to setup.

Merging algorithms often show conflicts that are too easy to resolve

Move to a DVCS instead as SubVersion is non-DVCS. If you do temporarily need to version control binaries, SubVersion is far more suited than Git. There are a few Free subversion providers available, but they are slowly disappearing.

How to version changes in code

Version control is necessary with any team, 2 or more. This is simple. Easy enough for any level. And the clear visualization of diffs with TortoiseSVN is fantastic.

I suppose most people prefer git. But I still like good ol SVN

Version control. I love that you don't have to check out a file. If 2 people are working on the same file, you can very easily merge the updates.

- easy to learn

- easy to setup on own environment

- flexibility in setup (configure hocks, access privileges etc.)

- good GUIs (Versions.app etc.)

- commit conflicts

- performance in general

- repository size

Check out Git as well.

We are a team of five and we work on mid sized web development projects with Subversion. From time to time we include external developers into our own Subversion environment.