A way to rename files while keeping the history is essential to any decent VCS.
CVS, well, does not cope at all with renames. We implement a crude way to deal with these by using direct repository intervention through the CVSmeisters (with all the risks that approach entail). Renaming a file is done through a direct copy of the <file>,v files from one place to the other (note that because we may have tags and branch tags within the files, we do not use mv even though the file moves. We use cp instead then mark the file as deleted).
SVN supports renaming/moving files via the svn move (doc) command. It relies on the fact that in a given point in time (understand revision, revision numbers are per-repository) only one object can occupy a given path. To unambiguously refer to a file one can further specify at which point in time (revision) did the file occupy the specified path. To implement this SVN introduces Peg revisions.
hg mv is the way to rename files while retaining the history. Soon there will be merge-following-renames feature in Hg, sponsored by Sun. It means that if file "A" from repository "R" is renamed as "B" but "R" was cloned into "S" before "A" is renamed, then modifications to "A" in "S", the modifications will show up in file "B" in "R" when merging (XXX is that clear?).
Update - 2006-10-13
The merge-following-renames code has been written and is available starting at revision 8c36b33a27c7 in the current Hg repository.
Git is a content-addressable rather then filename-addressable system. In short that means that the problem with "merge-following-renames" that was described in the Mercurial section simply doesn't exist with git since files are tracked by their content instead of their name so it's clear when merging that content has been changed. The concept of content addressability is described in further detail in this post to the git mailing list: http://article.gmane.org/gmane.comp.version-control.git/46348
Supported (also see monotone:FeatureRename)
The rename command (also aliased as mv) will allow files and directories to be renamed without breaking forwards or backwards history. These changes can be committed along with content changes as a single revision. Commands that use the history, including log and merge and annotate, will follow files through arbitrary renames. Two revisions that rename the same original file to different names, or that rename two different files to the same new name, will (correctly) cause a conflict will need to be resolved before they can be merged.