Do you take the entire asset management into consideration when planning your source control solution. For instance: images, external links, content, specs and data? I know there enough to wrestle with in getting source control to work effectively, but I often see okay source management, but manual manipulation of the other related assets.
(Added) This question was inspired by the StackOverflow podcast #36 http://blog.stackoverflow.com/2009/01/podcast-36/
Where I work we have all assets related to a project in source control, internal docs, third party API docs, code, DB SQL, content etc, the whole shebang.
We also make available business docs such as specs, project plans (no project server yet) via collaboration tools such as Sharepoint for non-development staff.
There's are some lines between Content Management, Configuration Management, Source Code Control and ordinary enterprise controls (i.e. SAS-70, SOX controls).
The two are distinct, there's no superset/subset relationship.
You have some enterprise information and you have the infrastructure to process that information.
Enterprise Information is data (not processing); this is often split between Content Managers and Relational Databases.
Content Management is an application you buy (or extend). It handles "semi-structured" and "unstructured" information. For example, images, links, and "content". Some folks call this "Asset Management".
RDBMS is an application you buy. It contains structured information.
Ordinary Enterprise controls should cover all of this "production" data -- content and RDBMS. If they don't, no amount of content management or RDBMS software will help.
Infrastucture is largely processing (not data). You must apply configuration management as a discipline. Configuration management includes all of the run-time configuration parameters, settings, files and what-not as well as source code.
Your source code control and your configuration is part of the processing of the enterprise information asset.
I suggest you focus on configuration management -- source code, settings, parameters, patches, etc.
Content, like the data in a database management, is the responsibility of the users, not the developers. Technical folks provide the RDBMS or content management tools. But technical folks do not take responsibility for the use of the information -- end users own the information -- they can do with it as they please.
Content Management (or "asset management") will be manual. You can buy them tools, but the users need to develop their own processes for using those tools. And it will always seem manual.
In the company I'm working at, we as developers agree, that everything changing during the life cycle of our product(s) and is manipulated by different people should be hosted inside the version control system. I went through that discussion several times with the different departments and it always ended in 'Sounds good, but people outside development can't handle version control systems'. So we do not have specification etc. under source control. Even worse, we have parts of the code, e.g. java-resource-files which are edited by non-developers, who allegedly are not able to work under source control and therefore we are forced to check files out, email them to translators, these editing the files, sending them back and we check the results into sc again (but have probably worked on them in the meantime :-( and merge)... which is actually the short version of what really happens (even MS-Excel is involved).
So, my answer is 'Yes, everything should be under source control.', but nothing but code ever will.