Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SVN: Best way to share common code across projects

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?

like image 959
aleemb Avatar asked Mar 21 '09 17:03

aleemb


2 Answers

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

like image 122
Epcylon Avatar answered Oct 01 '22 08:10

Epcylon


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.

like image 21
leander Avatar answered Oct 01 '22 08:10

leander