Changing the way I think about managing SCM repositories

Every now and then I read something or have a thought that affects the way I think about something so greatly that I feel compelled to tell others about it. Since this blog is the only way for me to tell those that might care, (I don't think any close friends or family care about different ways of managing SCM repositories) I'm doing it here.

Today during my lunch break I was over at Eric Sink's blog reading the latest chapter in what feels like a mini online book he's been writing lately on Source Control "How To". This chapter - on repositories - had a particularly interesting section that caused me to pause for a moment and think about what I just read:

"Best Practice: Use separate repositories for things which are truly separate

Most SCM tools offer the ability to have multiple distinct repositories. Vault can even host multiple repositories on the same Vault server. People often ask us when this capability should be used.

In general, you should store related items in the same repository. Start a separate repository only in situations where the contents of the two are completely unrelated.  In a small ISV, it may be quite logical to have only one repository which contains every project." 

In the two and a half years I've been working where I'm at now - where I'm actually responsible for the standardization of our VSS project structure - we've had a single repository full of all the code for all the work we've ever done. Now granted, there was plenty of logical structure built into the project hierarchy but, it's a rather messy and inflexible way of maintaining your SCM repository. I thought to myself:

Why did it naturally make sense to me to create separate databases for unrelated tables, yet it never occurred to me to create separate SCM repositories for unrelated code?

So today I decided that from now on - to the point that it makes sense - we're going to have separate VSS repositories for each major project we carry out or piece of software we build. I was immediately able to think of several advantages to doing this:

1. You can do a top level "GET" (/$) without worrying about dragging down a bunch of data that's got nothing to do with what you're working on.
2. You have more flexibility in setting working folders.
3. You can more easily manage the security related to which people get access to certain code.
4. You can perform compact/archive/backup operations on only the repositories that need it.
5. If you migrate to a SCM tool like Vault - you can import only the repositories you want to be managed by Vault, and keep others managed by VSS.

In a way I feel like perhaps I've been missing the boat here and there are many development shops already doing things this way. Is that true? How do you manage your SCM repositories?