2

So I have a shared code base which is Laravel + custom bundles.

However, we deploy multiple sites that depend on this common code base. We tag stable releases to the base and use a tag to deploy a site. So far so good.

What is the best way of attacking my problem of making a new project (a new website?) I make a new repository specific for that site, should I svn export the base project into my new repo? Or should I svn checkout so that I can update later?

Some factoids:

  1. I have access to php artisan
  2. I have access to my own dev server
  3. Id like to keep using SVN because of issue tracking
  4. Im willing to use BUILD options, or deployment packages. But these seem very hard to set up.
WiseStrawberry
  • 317
  • 1
  • 4
  • 14

2 Answers2

0

I'd not handle this in source control, but rather in packaging or deployment. Have the deploy script grab the version of the common code and then the latest (or whatever version of the other).

thekbb
  • 7,668
  • 1
  • 36
  • 61
-1

A possible solution could be to create a new repository for the new website, but include an external reference to the repository containing the common code base via the svn:externals property.

http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

This way, your new website could get the latest changes to the code base. However, any changes to the code base would have to be made to a working copy pulled directly from the base repository and not the repository containing the new website, which is probably what you want anyway.

bahrep
  • 29,961
  • 12
  • 103
  • 150
jsumrall
  • 111
  • 7
  • svn:externals are a really poor substitute for dependency management or sane package/deploy. It's a near truism that if you have the chops to not screw it up, you'll do something else. For a good read: http://stackoverflow.com/a/345404/505191 – thekbb Apr 09 '13 at 15:49
  • Thank you for the comment and the link. I found them to be very informative. – jsumrall Apr 18 '13 at 13:59