SVN: Best way to share common code across projects

Question

I have multiple website projects in a single repository each of which have a copy of WordPress. Updating WordPress means updating all project folders and keeping redundant copies. This is useful for my rsync scripts which sync the entire folder. It also gives me fully working local copies of the site.

There are a number of ways I can see of improving this and would like some feedback. I'm on Windows and recently migrated to Subversion.

1. Create symbolic links to the WordPress bits in each website folder. Will this hold up in Subversion and Apache. Any drawbacks?
2. Have a single WordPress folder and branch it into the other website trunks. I read that branches are cheap and a single copy is maintained but I am not sure if branching should be done across trunks. Personally, I think this is the best approach. Is there any reason to avoid this?
3. Lastly, I could keep the current structure and use a script to make copies across all website folders.

What's the best approach and are there any alternate solutions?

Answer 1

One option would be to separate the WordPress bits out into a separate repository (since it's not really part of your projects, it's just something you use to build them), and then use svn:externals to fetch that into your projects in the correct locations.

Externals Definitions in the SVN book

Answer 2

You could add a svn:external definition pointing to the WordPress repository or make your own separate "customized WordPress Repository" with the plugins and customizations you use.

Answer 3

Maybe I'm just using Subversion the wrong way, but our folder structure looks like the following

Trunk - Core - Messaging - Super Powerful Application #1 - Super Powerful Application #2 - Super Powerful Application #3

So all our apps share the same Core and Messaging components. The only downside to this is that when people branch, they get all the applications, but thats more of an annoyance than anything.

Answer 4

It often happens me reusing the same class libraries for different projects and in my case I prefer having a separate - freezed - copy for each project. The only reason being that I don't want to break projects I haven't worked on for a while in case one of the libraries outdates it. However if each project is a part of a sort of main project you are constantly working on it's different.

Answer 5

A better way to do this is to pull wordpress out into a separate branch of your repository. Then, introduce a config file to each one of your websites that stores the path to Wordpress. You can append this location to your php include path. Here's a diagram:

Svn repo-v
         |-Websites--v
         |           |---One
         |           |---Two
         |-Wordpress-v
                     |---branch one
                     |---branch two

This has a couple of advantages:

• You can experiment with several versions of Wordpress at once, to do testing and what-not. You can share these between all websites
• You won't have to worry where wordpress is check out to. Including a library within a project is often messy, but this type of setup makes it easier to put things in some common location.
• You don't have to maintain multiple versions of the library, updating is a lot easier.

Answer 6

Traditionally everything should be separated on SVN. It sounds like you're using SVN as a means to grab code from different areas and stitch them together.

So you're using SVN as a build-tool. It's better to :

• keep your plugins separate
• don't store wordpress itself in SVN, unless you use a vendor branch
• when you need to grab a specific app with specific components, work with a build-script.

Answer 7

If you're already hosting all of the sites together in one repository, svn:externals can be used to pull different parts of the same repository together in various ways.

E.g. with a repository like

repo/site1
repo/site2
repo/commonPieces

You can introduce an "svn:externals" property on the site1 and site2 dirs that says "commonPieces url-to-repo/commonPieces".

You'll want to avoid any recursion loops here obviously. But this has the advantage that everything's in the same repository and can share history -- you can pull things that are becoming more common from site1 or site2 into commonPieces using "svn copy".

Compare our current solution where I'm working -- migrating stuff from our separate project repositories into a single also-separate "coreLibraries" repository loses the development history. Since we commonly develop features for one project and then decide to re-use them, this loss of history happens a lot...

---

Edit: it's worth remembering that while "svn update" on site1 will automatically update commonPieces with this "svn:externals" property in place, a "svn commit" on site1 will not show things that have changed in site1/commonPieces. You'll have to make two separate commits, one from site1 and one from site1/commonPieces.

Answer 8

What's the best approach and are there any alternate solutions?

Not to go off topic, but I suggest you take a hard look at git. We do this kind of thing day in and day out with submodules, and it is a breeze.

FYI - migrated from SVN about 2 years ago due to these type of issues.