== The mixed directory/unrelated files VCS problem To follow up an [[earlier entry RCSvsModernVCS]], one might sensibly ask what the problem is with using a modern, whole-directory version control system on a directory full of unrelated files, the classical example being _/etc_. What you effectively have in this situation is a directory with multiple 'modules' (files and groups of files) that are logically separate and independent from each other. As they're separate modules, these files usually evolve and are developed at least somewhat independently. Putting all of these files into a single repository creates a mess in the same way that developing several different bugfixes at the same time in the same source code repository does. As with source code, what you wind up with is a repository that can give you time-based snapshots of the state of your directory, but doesn't tell you very much about the logic of development of various things, at least not in a straightforward way. (You can sort of reconstruct it by restricting various repository operations to just a subset of the files, but you are working outside of things.) This mess gets worse if you need to synchronize changes across multiple machines. Here, you really have the classic [[entangled changesets problem ../tech/VCSDependencyProblem]], especially since not all 'modules' may apply to a particular system. Updating a system to the current state of, say, your overall NTP configuration becomes a non-trivial operation because you're fighting how the VCS wants you to work. With some VCSes (eg, [[git http://git-scm.com/]]) I think you could cheat madly and sort of make this work, but I also think that you'd wind up with a lot of heartburn. With others, I don't see how to make this work short of having completely separate repositories for each machine and just shipping patches around by hand. (Okay, I suppose there are various [[cherry-picking http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html]] and [[transplanting http://mercurial.selenic.com/wiki/TransplantExtension]] extensions for various VCSes, but I suspect that significant use of them will wind up with an increasingly horribly tangled repository history.)