Nested version control scheme?

Looking for suggestions on how to best track this project structure in some sort of 开发者_StackOverflow中文版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?

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.

Maybe submodules would work for that use case.

You don't need to create repos inside repos. In fact, if you use subversion, for example (in git it is similar), when you want to create a branch you can do it by copying (svn cp). Subversion does copy-on-write (or copy on modification), so you can work in separate directories that will be kept separate. Then you can merge the changes in each branch (subdir).

Avoid big ball of mud^H^H^Hcode. Use separate branch for each code line you want to deploy. If you plan to migrate changes between branches, it's the best way, because you'll be able to manage changes between commits for each branch separately.

Common code can be kept in default branch (master or trunk, depending on your scm of choice).

You should use automatic deployment from scm, then you can configure it so, that it will deploy only selected branches.

My hunch is that coupling the common framework too closely with the separate versions will cause headaches. Perhaps this would work better:

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

The discovery section would manage a list of engine versions and their current state. Each engine version would be completely stand-alone. There's no direct link from the discovery section to the engine deployments, it's just a way to publicize which versions are currently running.

The deployments from version control would then be fairly standard to each engine version's directory.