VisualSVN and class libraries are not in the root copy of the working copy

Question

We are moving from SourceGear Vault to TortoiseSVN with VisualSVN to integrate with Visual Studio - absolutely love it. However, there are several class libraries that we reference in several different applications that are not part of the working copy root in any of the applications. What is the best way to handle this so that we can continue to use Visual Studio integration, but still maintain libraries of different classes located outside of each project / application root? SourceGear has no problem with this.

You can add class libraries separately using TortoiseSVN in Explorer, but there is no way to make changes to anything outside the working copy from Visual Studio; also there is no "traffic light" VisualSVN indicating the status for them outside the working copy class libraries.

By the way, we also use the “one repository with many projects” route, and not several repositories, especially since we have been working for many years up to this point.

UPDATE:

I re-read some of the things that I looked at earlier, and found that svn: externals not only refer to the use of 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 problem? There is a good stream that goes through things, but does not completely resolve things.

Hence use svn: externals or not? Use multiple repositories or not? Again, for many years, we have referenced code in shared class libraries among many solutions / applications, and this works for us. Now what is the best way to do this work with VisualSVN?

Answer 1

The best answers found here :

Related projects

It is sometimes useful to create a working copy consisting of several different checks. For example, you might want different subdirectories from different places to the repository, or even from different repositories. If you want each user to have the same layout, you can define svn: externals properties.

And here :

Enable shared subproject

Sometimes you need to include another project in a working copy, perhaps some library code. You do not want to duplicate this code in your repository, because then you will lose connection with the source (and supported) code. Or maybe you have several projects with common kernel code. There are at least 3 ways to handle this.

Answer 2

I understand that more than ten years have passed since you asked this question, but I am pleased to inform you that progress has been made in implementing support for multiple working copies in the VisualSVN plug-in.

VisualSVN 7.1 and 6.5 support multiple working copies in one solution . New features are available for users of Visual Studio 2019 and 2017 .

Download the latest VisualSVN builds from the download home page . See also KB7: Using Multiple Working Copies in VisualSVN .