I am about to set up an new laptop and in the process transition to a new version control system as part of a general cleanup. Currently I use a centralized version control system (yes it is VSS, and yes I know all the pro's and con's of that system, but as a single user system it works well for me). I have very little requirements for a new system and I am free to choose among any of the current mainstream players, but cost constraints will push me towards oss. Some of my requirements are:

• Runs on a single machine (ie the laptop in question) under windows
• I am not sharing things with other developers or workers - this is more for my own historical benefits.
• I want to version source code, documentation and binary files
• I have a large hierarchy of projects that are unrelated (see below)
• I have files within the hierarchy that don't need to be controlled (but could be)
• Some projects use Visual Studio, so some integration there could be nice.
• There could be some sharing of files between jobs.
• I generally only need a small about of branching in code files

The directory hierarchy that I have at the moment is somewhat like:

Root
 |
 |--Customer #1
 |    |
 |    |--Job #1
 |    |    |
 |    |    |--Data files received from Customer for Job (not controlled)
 |    |    |--Documentation files (controlled)
 |    |    |--Project information files (not controlled - but could be) 
 |    |    |--Software Project Files (controlled)
 |    |    |--Scratch dir for job (not controlled)
 |    |    
 |    |--Job #2
 |         | (same structure as above)
 |
 |--Customer #2
 |    |..
 |
 |--Cusmtomer #n
      |..

Currently I have about 22 customers with differing numbers of projects underneath them.

At the moment I have a single VSS repository based at the root of the directory structure. If I kept with a centralized system (ie SVN) I believe that I should keep the same approach and continue with a single repository based from the root dir. Is this a valid approach?

However if I move to a distributed tool then I am unsure of how I should handle the situation. My initial guess is that I should not have a repository based on the root of my entire directory structure - but that is a guess so I really don't know how valid it is.

Should I pitch a distributed approach at the Root, Customer, Job or sub-Job directory level?

Also what I am not clear on with distributed tools (and perhaps with SVN as well), is if I can branch parts of a repository. For example, I can see branching source code in software projects as being useful, but branching my documentation as not being useful. So if I pitch a repository at the Job level, can I just branch the Software Project Files? Or would all files in that Job be branched?

Every time I look at distributed tools I get a nagging feeling that they are not suited to my style of setup. I am uncomfortable with idea of having to manually set up something like 50 to 80 separate repositories (if I pitch at the Job level, or 20+ if at the Customer level) within my directory hierarchy. This feeling also extends to having all those repositories scattered around as well - however I do have a backup strategy that I trust, so this latter feeling is pretty well unfounded.

So what advice can you all give me? Thanks in advance!