Little Subversion trick to improve VisualSVN

VisualSVN is a great product. It is stable, intuitive and if you know TortoiseSVN - you pretty much know it all. Until (relatively) recently, the Ankh was practically the only Visual Studio plug-in for the Subversion. Unfortunately, it suffered from performance and reliability problems and lost a lot of trust. They claim that problems are solved, but I personally would need something very convincing to try it again. Like a direct order from management.

Unfortunately the VisualSVN is not resolving the old problem with multiple working copies (you know - when you have a framework and share it between numerous solutions). For some reason neither a Subversion nor a Team System approve of this very DRY approach. As a result the Solution Explorer in the Visual Studio doesn't track the changes in the project which resides outside the solution's working folder. Not a big deal if the framework is stable but it becomes pretty annoying if some work is still being done.

To overcome this problem in the Team System you had to sacrifice a black lamb on the intersection of six roads at a full moon and hire a Gemini-born Microsoft consultant within forty days. Subversion provides a more environmentally friendly solution - the svn:externals property.

svn propedit svn:externals Framework http://svn.repository/Framework/trunk

If you use this property on the main solution folder, the framework project will be checked out inside it and become the eligible (and version controlled) part of the solution. Instead of using the single physical copy of the framework project you would have multiple underneath each of the solutions but all of them will be tracked to the single code base in the SVN.

The svn:externals property still seems a little bit like a hack and has some stability issues and limitations with branching. Nevertheless it is a reasonable solution - the SVN properties can be managed by a build master and developers don't really need to do any extensive learning.