How to svn a complete cms installation (how do you manage official cms core files with your own modules)?

Question

I've read some topics that were suggested by SO ("The question you're asking appears subjective and is likely to be closed.") but couldn't find an answer to what I was looking for.

I'm using Joomla in a project. With Joomla, I have about 8 different third party modules, each one with it's own difference version number and Joomla compatibility. Some may be really up to date to Joomla's version (now it's 1.5.10), some may be not. Some of the modules were made by us. They all work and all of them are needed to accomplish the requirements of our company's website.

Fact is: what is the best way to put all of this in source control? Do you "bundle" the Joomla source code inside your repository, even if it's third party and it's VERY unlikely that you will modify these files? Or you just svn the core files that are really under your control?

IMHO:

The advantages of putting Joomla's core files inside the repository is that I can create tags and have a complete system in a time if a need it, without reading a possible documentation txt file saying "these modules are compatible with joomla X.X, joomla componet X.X with joomla version X.X" and such.

The disadvantage is that in putting files that arent going to be really versioned, unless when there's a new joomla version.

What do you think is the best idea? What do you usually do when your project (like our portal) is made by a lot of different components from different sources?

Answer 1

We typically include compiled versions of third-party modules in their own folder in SVN. Build scripts (or external: properties) can then be used to copy them wherever they need to go.

Answer 2

I would make a 'deployment state' specific tree which uses svn:externals to point back to my custom Joomla, my modules, etc. - each in their own tree. The 'deployment tree' would only be tracking how the modules are aggregated.

Answer 3

First, if your change is generic and an improvement, then you should submit it back to the project.

Otherwise, put it into your source control. Copy over the changes as they come and merge them in. In other words, treat the "real" source repository as if they were another developer.