For many of us - especially working on smaller games - you absolutely should have assets in the same repository as your source.
The suggestion that assets belong in a separate repository only makes sense for very large sets of assets, or for somewhat-large sets of assets when there's a clearly defined engine/data boundary. Unless there's a specific technical reason for it - it's bad advice!
You want your version control to behave like version control. You want to be able to rewind and fast-forward and branch and merge revisions and still have your game working. And your code and assets will depend on each other.
For example: Your code might expect to be able to set a parameter on a shader, and that shader might depend on a texture being there. Or maybe the data format of your levels might depend on a particular version of your game code.
It almost certainly will get messy. And you have better things to do than to try and keep it tidy.
Now, as Mike Wagner commented (on this answer) - you don't want or need all the "in progress" versions of your assets under version control! Just the final/working version, as used by your code, will do - often this is what you export from your tool.
(Although if you do want to version-control the in-progress versions of assets - that's fine. And well suited to a separate repository. I personally find that good folder organisation and a proper backup system suffices.)
That being said - it's sometimes nice to have the option to just stick "in progress" assets under version control. Typically this involves having a content pipeline that can handle any 'export' steps for you - for example: flattening a multi-layer image to a single texture.