We have used a file system organized hierarchically by:
- geographic extent (country or continent)
- data provider, licensor
After that we have a policy to separate the source data (in the same format that was on whatever CD/DVD that we got from the provider) from any derived datasets that we produced within our company.
The file system makes it really easy to ingest any data from the customer and also allows for some flexibility in terms of the physical storage - we keep our archives on larger, slower disks and we have special file servers (transparently linked into the hierarchy) for the more frequently used datasets.
To facilitate management within projects, we use symbolic links. We keep our vectors in a database (Oracle) and we make it a rule to have at least one database instance per customer (and several users/schemas for the projects). We haven't been keeping many rasters in a database, though, as they tend to take too much space even outside one. Also, we like to keep our database instances as lightweight as possible.
And yes, we have someone in charge of 'policing' the whole thing so it doesn't get too messy.
The biggest issue we have with this setup currently is the lack of a nice user interface which would help us have a better overview over the whole thing, and we've been planning to include a metadata storage on top of all that. We're still considering our options here.
We're using version control for our code and we've used it for documents, but it turns out that version control isn't really made for large datasets, especially if they're mostly binary files, so i wouldn't recommend that, except if you're dealing with GML or something similarly text-like (problems include huge overheads on the server-side disk usage as well as clients crashing when checking out huge repositories).