We use svn at work, but the repository is getting pretty large, so checkout times are long, as is update when artists batch process all assets.
The problem is that we also store work in progress, prototypes, small tests, legacy stuff and other 'junk'.
Now theoretically, some of it can remain local and uncommitted until it is ready to be included, and a lot could be deleted and cleaned, but that's irrelevant for this question.
Imagine a new asset, a level for example. The artists and designers want it shared and in version control so several of them can work on it, but everybody else does not need it.
Obviously multiple repositories are an answer: one for artists, one for programmers and one for the main project (for testers, building demo versions and finally the main product), which would be really tight and minimal, with everything needed for the game and no more. And then when an asset or some code is 'mature', it can be copied into the main project and committed.
Here's my questions: is it possible to have multiple repositories overlapping so that the artists can have one with everything they need, likewise for programmers. And only when ready commit the same file into the project repository too? This would eliminate bloat of having multiple copies of files and avoid conflicts between repositories.
I know old svn versions stored invisible files in all directories, so it would be impossible, but new svn versions store all meta data in the root directory right? So it might be possible.
I imaging the answer will be 'impossible', or even if possible, yuck! I suppose it would cause all kinds of headaches. Like checking it out in one repository would mean it would need to be committed/deleted in another.
But how about making a svn_commit script, that overrides svn commit with additional checks and housekeeping?
This is just a thought experiment really. I was wondering if anyone has ever done anything like this, and what would be the issues to be resolved. Cheers