Choice and setup of version control
- by Peter M
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!
