How should I organize source control for framework-based projects?

I'm struggling trying to sort out what the best-practice is for putting a project under source control when the project is written against a framework. In my situation I will be using Mercurial for source control.

Most PHP frameworks have an 'application' folder where I'm supposed to put my code that interacts with the framework. So is it best to put the application folder into it's own repository and then have another repository for the framework files? Or is it better to put everything, including the framework, into a single repository?

I'd like to be able to have a decent amount of flexibility, namely I'd like to be able to swap out t开发者_如何学Pythonhe version of the framework I'm using for experimentation while still being able to publish changes using the stable version.

I have experience with both the Kohana and Zend Framework frameworks so if you could use those as references that would be fantastic.

---

Well i dont use Mecrucial but perhaps my typical set up with Subversion will apply after you translate it :) I dont use a local centralized installation. I fnd that more often than not ill be using a specific version for each application i work on given the fast releas cycles of frameworks. So i always embed them within a project.

For Zend:

svn/path/
  trunk/
    application/
    library/
      Zend/  
      MyNamespace/
    public/
    data/

I use an svn:external to the version of the framework i want.... for example: http://framework.zend.com/svn/framework/standard/tags/release-1.10.5/library/Zend

For Symfony its much the same using externals for both symfony and any plugins. the difference is libraries like symfony and Zend i would put in a vendor directory instead of directly in lib:

svn/path/
  trunk/
    apps
    lib/
      vendor/
        Zend/  
        symfony/
    plugins/
    web/
    config/
    data/
    cache/
    log/

---

On my Kohana projects using git, I set up the entire project as a repository. This includes the application folder as well as modules and system. The system folder is a submodule pointing back to Kohana's latest stable. The modules can be normal files in the repo or they can be submodules as well. I also have a folder for the public_html files.

You can see how one company has it set up here: http://github.com/synapsestudios/kohana-projecttemplate

For development, you can make a new branch of your project and check out whichever version of system or module files you need to test with.

---

Assuming SVN there is this nifty feature called svn:ignore where you can mark files/folders or sets of files/folders as `ignored'.

This allows you to mix the files that should be versioned with the files that shouldn't; so it is really useful for libraries (and hence frameworks): only version your own source code and mark the rest (generated files, libraries) as ignored.

Possibly add a readme which documents what libs should be installed and how for use when others use your code, or when you want to setup a copy working environment on another machine.

Note that pretty much any other version control systems tends to have an `ignore' feature, it's not specific to SVN.

---

Very similar to svn, hg uses <root>/.hgignore to ignore files/directories (remember to add .hgignore itself as an entry).

I have no experience with either framework, but I can't think of a scenario where you want to track the framework and your application code together, since they definitely will progress at different pace. The framework code should have its own version control anyway.