Our use of Subversion at work is going fairly well, although we're not exactly using it heavily. I still haven't migrated anything other than our website to it, but I find that knowing how Subversion deals with revisions is affecting my use of CVS.
The CVS view of the world is based on it's ancestor RCS: each file is managed individually, so each file has it's own separate revision history. The ability to commit several files at once in CVS is just a convenience: each file will get a separate revision, and each file has it's own sequence of revision numbers. The only way of tying revisions together in CVS is to tag several files at a particular point in their history, but tags are really just useful labels, outside of the real history information.
The biggest improvement Subversion offers is that it knows about the directory structure, and stores changes to that structure as part of the revision history. Because of this it considers a revision to be a global thing, applying to the whole repository. So while CVS numbers revisions separately for each file, Subversion has just one overall sequence of revision numbers.
I've now started thinking of each commit as a single unit of change that implements one bug fix or one new feature. I'm even applying this to CVS, by carefully committing all the bits that implement a particular feature in one go, with the same commit message. The Subversion import script will notice that and make it into a single commit when I migrate everything to Subversion, and I find it helpful to think of things that way too.