Subversion is not an SCM tool

Subversion (SVN) is not a Software Configuration Management (SCM) tool. It is a Version Control tool. Basically, Subversion is nothing more than a versioned directory tree with a few version control features.

Let me try to explain why I think that Subversion is not an SCM tool.

No real promotion model
First think that is missing from SVN, and many other version control tools, is the ability to support only the most basic promotion model: promotion of changes from your private work area to the branch in the repository, and vice versa.
A real promotion model would allow you to promote between various areas as defined for your organization. For example:

• Private work area
• Private system build area
• Team integration area (also called the "stream")
• Build area (often running a continuous build)
• Test area
• Release area
• Staging area
  

In a real SCM system, you can define these kind of area and the rules (criteria) to promote between them. In SVN you cannot. What you can do is use branches - which are actually just a copy of a directory - and create a script or application to automate it (or do it manually).

No real baselines
A baseline is a reproducible configuration that is immutable (you cannot change it anymore). SVN does offer "tagging" but in fact it is creating a branch - which is a directory copy. The tag/branch is reproducible, but it is not immutable! You can still check out and check in on it, which is the normal way of making changes. Again, there may be workarounds, e.g. to remove write access for all users on the tag or by writing a pre-action hook that prevents check out.

No projects, teams or streams
Many software development organizations run more than one project at the same time, and/or have projects consisting of teams that work simultaneously. Projects will make baselines and teams will deliver to other teams. In SVN you cannot define integration areas (aka streams) for different projects or teams that are isolated from each other.
Again, we could use branches as a workaround; project-branches result in project-tags and team-branches are integrated (merged) with other team-branches and ultimately with the project-branch.

No change sets
Here is something you may disagree with. In SVN you can submit your changes in the work area to the repository. SVN does not create a change set for it, but it creates a new revision of the (whole!) respository. Of course, the new revision will be equal to the previous revision except for the changes you submit, but still SVN does not make a change set out of it. Nevertheless, you might argue that the submitted changes form a unity, which could be called a "change set".
The problem is however, that you submit all changes from your work area as a single change set, while in fact you may have been solving a problem report and implemented a new feature. If you want to identify the solution for the problem report (i.e. the change set corresponding to it) you are unable to do that.
A real SCM system is able to identify change sets related to units that are identified as managed items (e.g. work items, problem reports, change requests, requirements). Using a diff between revisions might be solution, but if branches are used to separate different areas, projects, teams and streams, the sequence of revisions in SVN or not so obvious. And again, adding a script to automate the selection of revisions to compare it adding an SCM feature that SVN is missing.

No roles
An SCM system is supposed to support an SCM process. One of the characteristics of an SCM process is that people can have different roles. Depending on the role, the process is different and with it the SCM tool behaviour is different. For example, a project leader is authorized to assign roles and the scope of control of a particular team or individual, but only for the project he is responsible for. These roles assigned privileges to the members of the teams.
SVN is able to assign read/write access to users at path level, but offers no means for roles like project manager, integrator, librarian, build master, developer, etcetera. Of course, you can implement this by hooks and scripts, but again you are extending SVN with SCM features that SVN lacks.

SVN does offer branching
Branching means that from a certain configuration (or revision in SVN) you create two - or more - parallel configurations. Typically, branching is intended to update a configuration from the past that cannot be implement in the current configuration (aka trunk, main, latest), for example a patch of a baseline. This is something that may be considered an SCM feature, which is supported by SVN.

Finally, SVN offers branching as one of the few SCM features. But reading back, I notice that many lacking SCM features can be resolved by applying branches for different purposes. If you are going to use the same technical solution to solve conceptually different SCM features, it will be quite difficult to distinguish between them: is the directory a promotion area, a project, a team, a stream, a baseline, a product, a component or module, just a parent directory to cluster projects, teams, streams, baselines, products, components, modules or just a leaf directory to cluster a number of files?
An SCM tool is supposed to help you implement an SCM process and a structure in the database. SVN only offers a versioned directory storage system. It's not an SCM tool.