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

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.

Answer 2

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 3

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 4

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 5

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 6

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.