Firstly, almost every common VCS is supported by an Emacs extension so that is not a key concern.
The only VCS that can output things to your drafts that I am aware of is SVN. To do this you have to install a couple of LaTeX packages, as described here: http://www.tug.org/pracjourn/2007-3/kalderon-svnmulti/ These allow you to put SVN version numbers and other details into your drafts. There is no real reason why this can't be done with other VCSs, but so far nobody has released any LaTeX packages for them.
I don't know of any LaTeX packages that allow you to track changes in the pdf itself, but they all allow you to do this for the .tex file via the various diff commands. Again, getting this in the pdf file would be a matter of writing LaTeX packages.
Aside from these issues, the main thing you need to decide is whether to use a centralized (e.g. CVS, SVN) or distributed (e.g. git, Mercurial) system. Distributed systems have a number of advantages and, as far as I can tell, no disadvantages for use with LaTeX. For one thing, you can use them without setting up a server to just work with single-author projects on your own machine. They also store the whole history of the project on your local machine so you always have access to it even if you are offline (one of my coauthors is very picky about this).
Personally, I use Mercurial rather than git for the following reasons:
- Git is undoubtedly more powerful than Mercurial, but the extra functionality is mainly relevant to software developers and you are extremely unlikely to need it for a LaTeX document.
- Mercurial has a better user interface in the sense that, unlike git, most commands do what you would expect them to do and you won't need to use lots of flags and command line options to get it to do what you want. (WARNING! The Git vs. Mercurial debate is an example of a holy war. This is the personal view of the author and you are free to disagree, but if you do disagree then it is probably because you have never worked with anyone who is not intimately familiar with a *nix command line.)
- Mercurial has excellent documentation, especially Mercurial:The Definitive Guide, which is available for free online. I didn't find anything nearly as good for git.
- Mercurial makes it easy to throw up a repository server on even the most backwards shared hosting provider that you can get for $5 a month. The standard ways of serving git repositories require persistent processes, which means you may have to pay more for hosting. Of course, this is moot if you run your own server or have in house IT staff to do it for you.
In summary, Mercurial will scare your collaborators who are only reluctantly agreeing to use a VCS in the first place a lot less than git would.