Choice and setup of version control

Question

Anyone? This question may also have been better on SO. So anyone for with the ability to do so, please feel free to bump it over.

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!

Answer 1

I'm using TortoiseSVN for myself with great success. Setting up a (file-based) repository is really easy using a blank new directory and the 'create repository here' option. TortoiseSVN appears to handle all work required to work with the repository so no extra installs are required.

Answer 2

I primarily use Subversion, and currently only know a little bit about distributed systems, so I'll speak from the SVN perspective.

If it's just you using the source control, on one machine, the advantages of distributed source control being, well, distributed, are reduced.

Subversion is a bit tricky to set up if done manually. However, there is a (free) package called VisualSVN that does the legwork for you, so you can just USE SVN, and not have to worry about setup or configuration.

If you're interested in Visual Studio integration for SVN, there are a couple of plugins I'm aware of: AnkhSVN (free) and VisualSVN (paid). The latter is from the same company that produces the free VisualSVN install package mentioned above.

So far as handling your multiple customers, each with projects, you could use a single global repository containing everything. Another idea might be to create a separate repository for each customer, each containing projects for that customer. You'd have a little more control over each repository this way, but there will be a little more overhead for you.

You mention branching projects. SVN does branching at the repository level, you can't branch just a particular subset. This would favour the per-customer repository idea mentioned above. However, in SVN, branches and tags are cheap, since they store changesets (deltas), not full copies. Distributed tools such as Git and Mercurial are optimized towards branching and merging, so the experience may be better with those - I don't know enough about them to say so for sure.

Hope that helps.

Answer 3

I have had good luck with Mercurial, using TortoiseHg for Windows. It is a distributed vcs, but the distributed features don't get in the way of using it as single user. I used it for personal history, and some programming projects and it worked well. Setup was pretty easy, less complicated than SVN if I recall, and it was quite easy to make and sync backups of my whole repository.