Does Subversion have changesets?

Yes, depending on your definition of changeset Subversion does some version of this.

For the purposes of this question, a simple definition of changeset would be a collection of changes with a unique name. The changes might include textual edits to file contents, modifications to tree structure, or tweaks to metadata. In more common terms, a changeset is just a patch with a name you can refer to. Subversion manages versioned trees as first-order objects (the repository is an array of trees), and the changesets are things that are derived (by comparing adjacent trees). Systems like Arch or Bitkeeper are built the other way around: they're designed to manage changesets as first-order objects (the repository is a bag of patches), and trees are derived by composing sets of patches together. In Subversion, a global revision number N names a tree in the repository: it's the way the repository looked after the Nth commit. It's also the name of an implicit changeset: if you compare tree N with tree N-1, you can derive the exact patch that was committed.

For this reason, it's easy to think of "revision N" as not just a tree, but a changeset as well. If you use an issue tracker to manage bugs, you can use the revision numbers to refer to particular patches that fix bugs - for example, "this issue was fixed by revision 9238." You can then run svn log -r9238 to read about the exact changeset that fixed the bug, and run svn diff -r9237:9238 to see the patch itself. The svn merge command also uses revision numbers. You can merge specific changesets from one branch to another by naming them in the merge arguments: svn merge -r9237:9238 branchURL would merge changeset #9238 into your working copy. This is nowhere near as complicated as a system built around changesets as primary objects, but it's still a vast convenience over CVS.