VisualSVN and class libraries not in the working copy root

Question

We're making the switch from SourceGear Vault to TortoiseSVN with VisualSVN for Visual Studio integration - absolutely love it. However, there are multiple class libraries that we reference in multiple different applications that aren't a part of the working copy root in any of the applications. What's the best way to deal with this so that we can continue to utilize Visual Studio integration, but still keep various class libraries located outside of each project/application's root? SourceGear doesn't have an issue with this.

It is possible to add class libraries separately just using TortoiseSVN in explorer, but there's no ability to commit changes to anything outside of the working copy from within Visual Studio; neither are there the VisualSVN "traffic lights" indicating status for these outside of working copy class libraries.

By the way, we're also going with the "one repository with many projects" route as opposed to multiple repositories, especially as that is how we have worked for years to this point.

UPDATE:

I re-read some things that I had looked at before and discovered that svn:externals don't just refer to using code in different repositories, but can also be used to use multiple working copies in VisualSVN.

See http://www.visualsvn.com/support/topic/00007/ and http://svnbook.red-bean.com/en/1.2/svn.advanced.externals.html

However, is this the best way to deal with this issue? There's a good thread that goes through things, but doesn't completely resolve things.

Therefore, use svn:externals or not? Use multiple repositories or not? Again, for years we have referenced the code in shared class libraries amongst multiple solutions/applications and this works for us. Now how best to make this work with VisualSVN?

Answer 1

Found the best answers here:

Referenced Projects

Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether. If you want every user to have the same layout, you can define the svn:externals properties.

And here:

Include a common sub-project

Sometimes you will want to include another project within your working copy, perhaps some library code. You don't want to make a duplicate of this code in your repository because then you would lose connection with the original (and maintained) code. Or maybe you have several projects which share core code. There are at least 3 ways of dealing with this.