I am looking to install on our local server a version control system. I've been looking at the pros/cons of the SVN and GIT, and even Mercurial.
We have about 30-35 different websites currently. Would I create 1 repo that contained all of them as folders? Also which would be better to handle all of these as individual website projects? GIT or SVN?
I am also going to have to install this on our Linux server, and create development sandboxes for developers. The people involved also use Windows and MAC.
I'm just looking for recommendations from experience, also instructional links on how to install them locally on the server.
As for APPS, I believe TourtiousGIT/SVN is good on windows, and Tower and Versions are good on MAC.
Let's try a balanced comparison, based on the premise that in your scenario you're probably not going to need any of the advanced features anyway.
Layout on filesystem: SVN requires two things, a working directory and a repository, for working with your data. Not only does this impose unnecessary duplication of metadata, but it makes things slightly more unwieldy. Both Git and Mercurial can keep your complete history inside the working directory (every working directory is a full repository). This is not too relevant if you don't intend on having a checked out copy of your files on the server (but it's a bit more complicated than that, anyway, so keep in mind that there might be other situations in which this whole bullet point does not apply at all).
Cluttering of working dir: SVN adds .svn subdirs in every subdir of your repository; Git and Mercurial only add a single .git/.hg directory at the top level.
Space consumption: Git and Mercurial use storage mechanisms that tends to be much more efficient than SVN's. The downside in Git is that the repository has to be optimized occasionally (which tends to be reasonably fast if you don't have extremely large files); I have no idea whether this is necessary for Mercurial but I suspect it isn't.
Conclusion: I recommend Git or Mercurial.
Since you probably won't even need the way better merging capabilities of Git/Mercurial, I don't see this as a deciding factor. This does not apply if you are planning on working on several sets of changes simultaneously; in that case, Git/Mercurial will probably make things much easier on you.
Git and Mercurial are notoriously faster than SVN, especially since their design allows many operations to be performed locally.
Looking at old stuff: in SVN looking at your history of changes means that SVN has to connect to the remote repository and look there; in (for example) Git the history usually displays before SVN has even established that connection.
OS-dependent: many of Git's optimizations apply mostly to Linux; you may experience worse performance on, say, Windows. The same might be true for the other contenders to a lesser degree, I don't know.
Transmissions: Git and Mercurial send and receive new changes much more quickly than SVN in almost any scenario.
Conclusion: Git and Mercurial are preferable if you like things fast. On Windows Mercurial might be a better choice, but please consult/perform actual benchmarks if you want to be sure.
Git and Mercurial allow developers to continue working on their things, and organise them in a sensible set of commits, even if they are not currently connected to your network. In SVN, commits can only be made at the same time as they end up on the server, so SVN users tend to use more monolithic (and thus more difficult to understand) commits. At least Git, on the other hand, even has a tool for quickly finding the commit that introduced a bug, using binary search. Again, SVN might come out on the bottom here.
I'm a huge fan of Git and I'll easily agree that Git is not the most user-friendly VCS, at least if you don't understand its design. For more advanced use cases, I believe that the toolchain makes up for that; in your case, you might prefer Mercurial or SVN unless you expect to be using the same VCS for more complex projects in the future.
I don't know Mercurial very well, so I'm not very familiar with what interfaces there exist for it. In fact I don't use any fancy-shmancy interfaces for Git, either, but I believe that there are plenty of tools for all of the contenders that allow basic usage for, shall we say, people who don't appreciate command lines. However, I'd strongly recommend that you do a bunch of small tests before you spring anything specific on your team.
Repositories tend to be structured differently for the different systems. In SVN it's okay to have a whole bunch of projects inside the same repository; Git and Mercurial strongly prefer having one repository per project. For shared code, Git has at least three tools (two of them third-party) for using external repositories, Mercurial probably has something as well. I know SVN has something like that, anyway.
If you do manage them as individual repositories, I would probably recommend Git or Mercurial because, as already said, they tend to have less overhead per repository.
Installing Git/Mercurial/SVN on your server is probably easy if you use any of the bigger Linux distributions; there are almost certainly ready-made packages available. If you anticipate having to manage a number of repositories with different per-user access control, there is a nice management system for Git called gitolite. Managing several repositories can be a bit of a hassle without something like that.