I've used CVS for years and it is a great tool, but it isn't perfectly
suited to Java, or large projects.  In Java class names are mirrored by
filenames.  Every time you change a class name you also rename a file.
CVS does not support renames.  Moving files around between directories
is also not supported.  In fact, directories are not versioned at all.
Dealing with binary files under CVS is a pain and ultimately ends up
with a new copy being stored every time a binary file changes.  CVS
commits are not atomic.  That means that if something goes wrong in the
middle of a commit some files may end up being committed and others not.  

All of these problems and several others are solved by Subversion.  In
addition the tagging, branching and version numbers simply make more
sense in Subversion and are easier to handle.

It is a much better tool and is intended to be the upgrade path from CVS.
You might also look into arch.  I don't know enough about arch to
intelligently discuss it, but it is an alternative to subversion.  The
Linux developers also have been developing their own tool, but I don't
know anything about it either.  

Subversion would be the natural choice.  

- --
Kenneth P. Turvey <kt-usenet@squeakydolphin.com>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: kpturvey@jabber.org
Phone: (314) 255-2199

Yes you can. However you need to identify the files as either text or
binary, usually using a configuration of binary/text extensions.

binary updates are not diffable the way lines are.

It depends. You probably want all three.  One for Singapore projects,
one for India projects and one for projects with members from both.

It is nice to have your CVS server locally on a LAN near the biggest
concentration of programmers for fast access.

There are a ton of ways of doing login.  For ease of use and maximum
privacy,  one possibility is having each machine having a private
certificate for auto login, over an encrypted channel.

That presumes your programmer machines are physically secure.

Your biggest practical danger comes from a disgruntled insider
deliberately and subtlely corrupting the repository and the backups.

One big problem with CVS is checkin is not atomic. If something goes
wrong part way through your checkin, half of it will be in and half
not. That leaves the repository in an inconsistent state that will
sometimes bring everyone else to their knees who has done a checkout.
If they don't understand what has happened they might not  recover on
their own until the original programmer recovers from his problem. The
problem magnifies with team size.

Subversion is a CVS competitor that deals with that problem.

Another problem with CVS is false deltas. Somebody adds a space or
breaks a line and it registers as a change when it really was not.  It
then becomes hard to find the real changes in the noise.

The solution is to insist that all code go through standard
beautification before checkin.  You can do this with an common
enforced Eclipse beautification configuration for example.

See http://mindprod.com/jgloss/cvs.html for more background.

CVS is well known and has hooks for example in Eclipse.  It is a bit
long in the tooth.

Subversion is the up and comer.

The others are too expensive for individuals. They may be just what
you need though.  I have links at http://mindprod.com/jgloss/cvs.html