Committing Changes:
SVN: svn commit -m "Commit message" (commits changes directly to the central repository)
Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository)
Deleting/Removing Files:
SVN: svn delete <filename> or svn remove <filename>
Mercurial: hg remove <filename> or hg rm <filename>
Branching:
SVN: svn copy <source_URL> <destination_URL> (creates a branch by copying a directory in the repository)
Mercurial: hg branch <branchname> (creates a new named branch within the repository)
Reverting Changes:
SVN: svn revert <filename> (reverts local modifications) or svn merge -r <revision>:<revision> <URL> (for more complex reverts)
Mercurial: hg revert <filename> (reverts local modifications) or hg backout <changeset> (to undo a specific commit)
One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.
Last year, unfortunately. Most modern utilities, even svn-to-git migration utilities, have been abandoned now that git has become the de-facto standard and everyone who can reasonably be expected to switch to git has done so already.
Svn has one great feature, you can checkout (clone) repo partially.
This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want.
I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches.
I'm not sure what I would prefer for a team project. I'm sure svn got decent merging.