We're in the process of a slow conversion from maintaining files with RCS to mostly keeping them in Mercurial repositories, which has wound up making me think about how we want to structure them and which of our existing directory areas are easy to convert. As a result of this, I have an observation: modern whole-directory VCSes change how sysadmins want to lay out files and directories.

In the old days of single-file version control, it made perfect sense to group files together in directories by function or system, regardless of how they were generated or updated. For example, you might put all of your local MTA-related files in a single directory, with some of them being automatically generated and some of them hand edited. You might even mix in binaries used by scripts and so on.

(The automatically generated files might or might not be maintained under RCS; the hand edited ones definitely would be.)

In a whole-directory VCS, this is a bad idea; you want all of those non version controlled files to be in a completely separate directory somewhere that's outside of the repository; you want the repository to only have 'source', not 'compiled things'. Otherwise, as a minimum you're going to wind up with a bunch of file exclusions (and it's my opinion that file exclusions are fragile).

(Unlike with RCS, you want to do this even if you keep the automatically generated files under version control, since an automatic checkin of new versions of the generated files could easily collide with other work you're also doing in the repository.)

There's two approaches for dealing with this that I can think of offhand. You can have your overall configuration know that some files are found in one directory and other files are in another, or 'publish' files from the version control repository to the directory that has the automatically generated files. Of these, I prefer the two directories approach on the ground that it's more robust (you don't have to remember an extra magic step to make changes go live).

(By the way, if you are building such a system you almost certainly don't want to require changes to be committed to the repository in order to be activated. Doing 'check out current version' or the like is tempting, but it's going to make testing much harder.)