Most version control systems today are multi-user, multi-file, and multi-fork oriented. These are all good features and properties to have, but they neglect the need to maintain simple single-file documents, such as HOWTOs and FAQs, much like the very file you are reading now. There is even a good use-case for small programs and scripts. Do you presently keep your ~/bin contents under version control? If not, consider using SRC for them."
OK, but I don't see how git having those capabilities makes it inappropriate for cases where you don't need them.
I guess I can appreciate the single-file revision control thing, since that is something git doesn't do well. But, I am usually OK with a whole directory being under revision control.
All the other stuff is irrelevant, I'm pretty sure. Don't want branches and tags (I guess that's what "multi-fork" is referring to)? Don't use'em. Don't want multi-user? Doesn't matter, git doesn't lock files, and the user never needs to think about users if they are the only contributor to the repository.
"Why SRC instead of $VCS?
Most version control systems today are multi-user, multi-file, and multi-fork oriented. These are all good features and properties to have, but they neglect the need to maintain simple single-file documents, such as HOWTOs and FAQs, much like the very file you are reading now. There is even a good use-case for small programs and scripts. Do you presently keep your ~/bin contents under version control? If not, consider using SRC for them."