SVN externals alternative in team foundation server 2012

Question

Currently we use SVN for our source control. Because of the extra features and integration in the development environment we would like to migrate to TFS 2012.

We have a lot of portals running that are build in asp.net. Within our portal we use a lot of standard components. Currently all portals use the same code base. This means that whenever we change something in the shared codebase it is (whenever a portal is published) automatically distributed. We are very used to this way of working and we know there is a risk of breaking code in other portals. Though, publishing changes in all other portals would cost way to much time. So to do this we use externals in SVN.

I would really like to keep this functionality up and running. So my question is, is there a way to create a external like system in SVN or is there a realy good way that works just as efficient to replace this functionality.

Answer 1

There are a couple of suggestion in the Visual Studio Team Foundation Server Branching and Merging Guide .

If you download the "Everything" package and look in "All Guides" zip and have a read of "Advanced Version Control Guide".

Pages 5-19 (Version 2.1) cover Managing Shared Resources, there's a lot there and summarising it all for Stack Overflow will probably do the Ranger's an injustice, so I'll just point you there.

Answer 2

Bottom line: No TFS does not have an equivalent to "svn:externals".

Code Sharing is BAD and leads to code duplication and not code reuse. Be dependant on compiled code instead.

You should be dependant only on the "output" of the shared library and not on the source files. As to scenarios, I can think of no scenarios where it is advisable to share source files between products/solutions.

The reason being is that things can get complicated an unwieldy very quickly. What if you have move than one dependant to a shared library that all make changed to the same code and they alternately break each other. The only way around that is to start branching your common code into the other projects which now adds a level of complexity and integration that will never get handled in the long run and you will end up with three or more versions of the same code base over time.

What you should do is have a single core component that is changed and build to produce output. This output can then be pulled on demand into the other projects that depend on those changes or not. This results in fewer breakages, better architecture and less technical debt.

You can even introduce NuGet into the equation using either a hosted on in-house server to publish your common component and notify each of the consumers when a new version is available.