Как организовать контроль источника для проектов на основе фреймворка?

Question

Я изо всех сил пытаюсь разобраться, какая лучшая практика заключается в том, чтобы поставить проект под контроль источника, когда проект написан против рамки. В моей ситуации я буду использовать Mercurial для управления версиями.

Большинство фреймворков PHP имеют папку «приложение», где я должен поместить свой код, который взаимодействует с каркасом. Так лучше ли помещать папку приложения в свой собственный репозиторий, а затем иметь другой репозиторий для файлов фреймворка? Или лучше помещать все, включая фреймворк, в один репозиторий?

Я хотел бы иметь достаточную гибкость, а именно, я хотел бы иметь возможность менять версию используемой мной рамки для экспериментов, сохраняя возможность публиковать изменения, используя стабильная версия.

У меня есть опыт работы с каркасами Kohana и Zend Framework, поэтому, если бы вы могли использовать их в качестве ссылок, которые были бы фантастическими.

Answer 1

Ну, я не использую Mecrucial, но, возможно, моя типичная настройка с Subversion будет применяться после ее перевода :) Я не использую локальную централизованную установку. Я полагаю, что чаще, чем не больно, использовать конкретную версию для каждого приложения, над которым я работаю, с учетом быстрых циклов цикла. Поэтому я всегда встраиваю их в проект.

Для Зенда:

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

Я использую svn:external версию рамок я хочу .... например: http://framework.zend.com/svn/framework/standard/tags/release-1.10.5/library/Zend

Для Symfony его почти таким же, используя внешний и для Symfony и любые плагины. разница библиотеки Symfony и Zend я бы поставил в каталоге поставщика, а не непосредственно в lib:

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

Answer 2

Предполагая, что SVN есть эта отличная функция svn: игнорировать, где вы можете пометить файлы/папки или наборы файлов/папок как «проигнорированные».

Это позволяет смешивать файлы, которые должны быть версированы с файлами, которые не должны; поэтому он действительно полезен для библиотек (и, следовательно, для фреймворков): только версия имеет собственный исходный код и помечает остальное (сгенерированные файлы, библиотеки) как игнорируемые.

Возможно, необходимо добавить файл readme, в котором указываются, какие библиотеки должны быть установлены, и как их использовать, когда другие используют ваш код, или когда вы хотите настроить рабочую среду на другой машине.

Обратите внимание, что практически любые другие системы управления версиями имеют функцию «игнорировать», это не относится к SVN.

Answer 3

Очень похоже на СВН, использует <root>/.hgignore рт.ст. игнорировать файлы/каталоги (не забудьте добавить .hgignore себя как запись).

У меня нет опыта работы с фреймворком, но я не могу представить себе сценарий, в котором вы хотите отслеживать структуру и код приложения вместе, поскольку они определенно будут развиваться в разном темпе. В любом случае, код структуры должен иметь свой собственный контроль версий.

Answer 4

На моих проектах Kohana, использующих git, я настроил весь проект как хранилище. Это включает в себя папку приложения, а также модули и систему. Системная папка - это подмодуль, указывающий на последнюю конюшню Коханы.Модули могут быть нормальными файлами в репо, или они могут быть подмодулями. У меня также есть папка для файлов public_html.

Вы можете увидеть, как одна компания она создала здесь: http://github.com/synapsestudios/kohana-projecttemplate

Для разработки, вы можете создать новую ветку вашего проекта и проверить, какой бы ни версии системы или модуля файлов, которые необходимо проверить с.