Making a souce repository available across a network, be it your office LAN or the Internet, can be an involved process. So for this task, I'm going to concentrate less on the specific mechanics and more on a high-level overview of the options and protocols available for each system. Pretty much every VC system supports multiple ways to network a repository; rather than give detailed instructions, I'm trying to evaluate the various alternatives for each system here.
There are two basic ways to do networked CVS: using CVS' insecure pserver authentication protocol, and through a remote shell. pserver is very insecure for two reasons: committers' passwords are stored unencrypted in their home directories (~/.cvspass), and they are sent unencrypted over the wire between the client and the server. pserver is suitable for use on a private, secure LAN, or for anonymous read-only access over the Internet. It should never be used for password-authenticated access over the Internet. The main advantage of pserver seems to be that you don't need to have a system account for every CVS user, e.g. if you like you can map all committers to a common system account. (There are variations on pserver, namely kserver and gserver, that add a layer of encryption to the network traffic. I have no experience with those protocols so have nothing to add.)
Shell access (the ext protocol) can be made secure, since it can use SSH as the transport. The catch is that committers need system accounts on the CVS server.
Regardless of the authentication protocol, CVS has a very unsophisticated network protocol. Specifically, it appears that the data sent over the wire is just about exactly the same as what the client writes to the user's console. Presumably that keeps the client code simple, at the cost of making life hard for anyone trying to implement a different client implementation that does more than simply dump the server's output to stdout/stderr.
Subversion offers two basic ways to get your repository on a network: via svnserve and via Apache. A third variation is svnserve tunnelled through SSH. Vanilla svnserve is quite easy to setup and does not require system accounts on the server, but network traffic is unencrypted. (It's a bit more secure than CVS pserver, though, since passwords are not sent in the clear.) svnserve through SSH is also pretty easy to setup, but requires that users have system accounts on the server machine. Enabling access through Apache is quite complex, but is the most flexible way.
The Subversion manual has a good summary of the pros and cons: http://svnbook.red-bean.com/en/1.4/svn.serverconfig.choosing.html