Nested version control scheme?

Question

Looking for suggestions on how to best track this project structure in some sort of version control (git or svn, preferably):

The project is for a web service that will have multiple versions of the "core" code, and users can create their instance of the web service with whichever "core" they'd like (of the available versions). In this way, development/beta versions will exist on the same server as the stable versions.

So there's multiple "cores" that exist, and will likely be different releases/tags/branches in version control. But then there's the overarching web interface that links them together, which needs to be its own additional version control project, for those web files.

From a structure standpoint, it would look something like:

/-+
  |
  +--index.php
  +--engine/
  |  |
  |  +--1.0-stable/
  |  |  |
  |  |  +--feature.php
  |  +--2.0-beta/
  |     |
  |     +--feature.php
  +--main.css
  +--main.js

So, the index.php, main.css and main.js are part of their own "project" which is the web interface, while 2.0-beta is a separate development branch, whose updates will eventually be merged into a 2.0-stable branch, and any hotfixes to feature.php in the 1.0 branch in would need to be merged into ito the 2.0 feature.php file as well.

Can I create repos inside repos? How would this best be managed?

Answer 1

If your directory structure doesn't have to look that way, I would have two repositories: one for the engine and one for the infrastructure. The engine repo has two (or more) branches and each of these branches has the infrastructure repo as a submodule (for git; or svn:externals if you went with SVN).

That way, you could work normally on the engine branches, but changes in infrastructure are shared. Of course, nothing is stopping you from creating more infrastructure branches later on, if that need arises.