Sharing Code with SVN Externals and Shared Repositories – 352 Noodles & Doodles

Sharing a development codebase among different teams and different offices can be a real challenge. Like many developers we use subversion to control and manage project repositories and to collaborate on projects. While there are other options like TFS or Git, if you’re using subversion or are planning to implement it, it takes some work to get off the ground. In this week’s Noodles & Doodles, I’ll walk you through how to share code using SVN externals and shared repositories. Enjoy!

Transcript below.

Image credit: Sander van der Wel

[Leo Rodrigues:] Hi, I’m Leo Rodrigues. I’m a Software Developer here at 352, and I’ll be talking about sharing code across multiple projects using SVN Externals. 
 
So first let’s define what SVN External is for reference. An SVN External is a property of subversion that allows you to configure a repository as a composition of other repositories. Referencing the drawing here I have a Project One repository and that repository is actually empty, but it is referring to three other repositories in my architecture.  Similarly I have Project Two, also an empty repository, also referencing one of the repositories in the architecture and Project Two code repository. This Project Two repository is choosing not to bring over global admin components from my pool of external repositories. So as you can see in this manner you can have any number of repositories down that would then be referencing any number of components that you choose to configure.  Now that we know what a SVN External is, let’s talk about some of the conditions that would apply to make it appropriate for you to make a decision to go ahead and use them. Number one, your team currently uses subversion. You’re not coming from a clean slate with the ability to say explore options like TFS or Git. You’re already using subversion, and you are familiar with it, so there’s pros there. You have the need to share a somewhat mature code base across multiple projects in your organization or for a particular client that is large enough that it’s spanning multiple projects.  And third, you have a very good reason to stay with subversion, whatever that may be. It could range from IT pushback to say that they don’t want to install another system within the organization, at least not in the near future, from you preferring subversion over other systems. Whatever your reason is, if you meet that criteria, then using SVN Externals as a solution for sharing code across multiple projects may be a good one for you.  Let’s talk a little bit about the setup; it’s quite simple to do. Here is an example. Let’s say this is an ASP.NET web forms website. You would have a typical file structure. All of these folders would be under the same repository, and you have things under your code. You have an admin tools area. I have a couple of components here as representations of a file manager and a content manager, CMS. You also have your code area, and your code; that’s where you’re default .aspx files would be, things like cascading style sheets, JavaScript and so on. You may have also other things like documents and non-code artifacts in your repository.  So what you do next is you set up a new repository structure. Let’s call that repository Global since we’re trying to share resources across multiple projects. We’ll set up here a folder called All Empty Sites due to the fact that the way I’m setting this up, my repositories are actually empty. I have a reference here to Project One. Then I have my areas that I’ve decided to extract out from the old repository structure, so I have the Admin tools as a separate component that I may choose to bring over to a project or not. As we mentioned before, the code area that will probably be in every single project that uses this type of structure. And here are your miscellaneous documents and other artifacts. 

A new addition to this structure is a new folder we’re calling a site to hold project-specific code that will not be shared across all projects. So what we’re doing here is we’re now splitting this out and placing or repositioning the files in the new file structure. So you would grab the all components under the admin tools, for example and create corresponding sub-folders and place the files in the admin tools area. You would grab all of your, all other things under code that are not worthy by your decision of being extracted out into a separate component area, and we’ll just simply place them under code. And your documents will go in the documents. 

Anything from your code that could be extracted out to be project specific, for example, you could duplicate CSS code to be both in the base, but also when applied specifically to a website or a project you would have styling to override the base to give a custom look and feel to a website. So you grab some of these components and put them under a Project One under the site.

Okay. Now we have the new repository structure defined. Next you have to set up SVN Externals for your particular project. So Project One under empty sites and again that repository is empty. The only thing you have to do is add SVN External properties to that particular repository. And properties are pairs of information. They have the target in your file structure that would be checked out to a local machine and also a specification of where the source would be coming from. 

So in here we’re mimicking exactly this initial file structure. We say that going into the code folder under the Admin Tools File Manager, that particular information will come from now the Global Repository Admin Tools, probablyfile manager as well. And similarly your main code will come from the Global Code Repository, and your site specific code would go to code/site and come from the Global site, Project One specific repository.

You add those properties, you commit them to the repository and then the result is next time you do a checkout of this repository you have the file structure exactly like this with the addition of the new site folder. And the beauty of it is you’re going to have the same exact look and feel of development in your old structure, but the source code you modify will be now shared across multiple projects. So you have that benefit of code reusability.

That’s it. Thank you for watching.