A little bit late to the party, but here is my idea.
I would go with the 3rd posibility which involves nothing like modifying the already existing code-base. This will work if, you will commit (and copy) the binaries (the actual game .exe and the associated .dlls from the compilation) somewhere in an output directory - for example with a post-build script. Onwards, I will assume we are talking about Visual Studio 2010 and XNA Game Studio 4.0 (The procedure is very similar for other versions, just need to replace some numbers)
So, the idea is: create a script (.cmd) in the root of your project, where the .sln solution resides, with the following steps:
Invoke the "Visual Studio 2010 Command Prompt":
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
This is in order for our script to be able to find the XNA libraries, and all the required tools and binaries.
Call the MSBuild task on the Content Project (.contentproj):
msbuild /property:XNAContentPipelineTargetPlatform=Windows /property:XNAContentPipelineTargetProfile=Reach mygame.content/projectfile.contentproj
You can modify the properties by specified different platforms/profiles. You can even go further to build the content for more platforms at a time (Windows Phone, Xbox 360 or Windows). The profile can be: Reach or HiDef (http://msdn.microsoft.com/en-us/library/ff604995.aspx)
Copy recursively the output to the folder where the binaries + actual game is stored on the repository:
xcopy /d /y /i /e bin\x86\Debug\Content* ..\game_output\Content
For details on the flags, you can invoke in the command prompt:
xcopy /?. The important ones are:
/d, to copy only modified files - in case you have many assets it's useful not to copy over and over again the already existing and unmodified ones;
/y for automatically overwriting existing files so they can be updated with a newer version. I've used
xcopy because the normal
copy can't copy recursively folders as far as I know - and probably you are structuring the content in folders and sub-folders. Plus, it's better than the normal
copy (lots of different flags).
pause so the script will wait for user input. This is useful to check if the build was fine and no errors were encountered.
Now, the artists (or anyone) who modifies the content files, need just to double click the .cmd script and the new content will be built and copied to the output directory where the commited artifacts are, ready to be tested.
However, there is a small problem, for which you'll have to fallback to the 1st point of David's post: if the artists want to modify the Content project by adding/removing/moving around files, they have to do that by opening the project in Visual Studio (or editing the project file by hand, which I doubt anyone would do). Like I said, this is a small issue, because they could just commit the new files in the repository, and you, the coder will include them in the Content Project when the code is done to handle those.
On this idea, Shawn Hargreaveas posted something about msbuild and building the Content Projects from command line: http://blogs.msdn.com/b/shawnhar/archive/2006/11/07/build-it-ahead-of-time.aspx His solution was to create a new file, but I think it's easier and more maintainable to use directly the already existing project file.
PS: Sorry for the long post xD