Как создать и хранить проект Symfony в субверсии

Tip

Эта запись конкретно о субверсии и базируется на принципах, которые можно найти в /setup/new_project_git.

Когда вы прочитаете Create your First Page in Symfony и ознакомитесь с использованием Symfony, вы без сомнений будете готовы начать ваш собственный проект. Предпочитаемым методом управления проектами Symfony является использование Git, но некоторые предпочитают использовать `Субверсию`_ (Subversion), что абсолютно нормально! В этой статье вы узнаете, как управлять вашим проектом, используя SVN в схожей манере с тем, как если бы вы использовали Git.

Tip

Это один из методов отслеживания вашего проекта Symfony в хранилище субверсии. Для этого существует несколько способов, а этот просто является рабочим.

Хранилище субверсии

В этой статье предполагается, что ваш макет хранилища следует распространённой стандартной структуре:

1
2
3
4
myproject/
    branches/
    tags/
    trunk/

Tip

Большинство хостингов субверсии следуют этой стандартной практике. Этот макет рекомендован в Контроль версий с субверсией и макет, используемый большинством бесплатных хостингов (см. Решения хостинга субверсии).

Начальная установка проекта

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

Как только у вас будет каталог вашего нового проекта и всё будет работать, следуйте этим трём шагам:

  1. Проверьте хранилище субверсии, которое будет принимать это проект. Представьте, что он находится на Google code и называется myproject:

    1
    $ svn checkout http://myproject.googlecode.com/svn/trunk myproject
    
  2. Скопируйте файлы проекта Symfony в папку субверсии:

    1
    $ mv Symfony/* myproject/
    
  3. Тепер установите правила игнорирования. Не всё должно сберегаться в вашем хранилище субверсии. Некоторые файлы (такие, как кеш генерируются, а другие (такие, как конфигурация БД) - должны быть настроены на каждой машине. Так используется свойство svn:ignore, чтобы конкретные файлы можно было игнорировать.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    $ cd myproject/
    $ svn add --depth=empty app var var/cache var/logs app/config web
    
    $ svn propset svn:ignore "vendor" .
    $ svn propset svn:ignore "bootstrap*" var/
    $ svn propset svn:ignore "parameters.yml" app/config/
    $ svn propset svn:ignore "*" var/cache/
    $ svn propset svn:ignore "*" var/logs/
    $ svn propset svn:ignore "*" var/sessions/
    
    $ svn propset svn:ignore "bundles" web
    
    $ svn ci -m "commit basic Symfony ignore list (vendor, var/bootstrap*, app/config/parameters.yml, var/cache/*, var/logs/*, web/bundles)"
    
  4. Остальные файлы теперь могут быть добавлены в проект и фиксированы:

    1
    2
    $ svn add --force .
    $ svn ci -m "add basic Symfony Standard 3.X.Y"
    

Вот и всё! Так как файл app/config/parameters.yml игнорируется, то вы можете сохранять настройки, специфические для машины (например, пароли БД), здесь, не фиксируясь. Файл parameters.yml.dist фиксирован, но не читается Symfony. А путём добавления любых необходимых вам новых ключей в оба файла, новый разработчики смогут быстро клонировать проект, копирать этот файл в parameters.yml, настроить его и начать разработку.

На этой стадии у вас есть полностью функционирующий проект Symfony, находящийся в хранилище вашей субверсии. Разработка может начаться с фикисрований в хранилище субверсии.

Вы можете продолжнить следовать статье Create your First Page in Symfony, чтобы узнать больше о том, как конфигурировать и разрабатывать внутри вашего приложения.

Tip

Стандартная версия Symfony поставляется с примерами функциональности. Чтобы удалить пример кода, следуйте инструкциям в статье "/bundles/remove".

Managing Vendor Libraries with composer.json

How Does it Work?

Every Symfony project uses a group of third-party "vendor" libraries. One way or another the goal is to download these files into your vendor/ directory and, ideally, to give you some sane way to manage the exact version you need for each.

By default, these libraries are downloaded by running a composer install "downloader" binary. This composer file is from a library called Composer and you can read more about installing Composer globally.

The composer command reads from the composer.json file at the root of your project. This is an JSON-formatted file, which holds a list of each of the external packages you need, the version to be downloaded and more. composer also reads from a composer.lock file, which allows you to pin each library to an exact version. In fact, if a composer.lock file exists, the versions inside will override those in composer.json. To upgrade your libraries to new versions, run composer update.

Tip

If you want to add a new package to your application, run the composer require command:

1
$ composer require doctrine/doctrine-fixtures-bundle

To learn more about Composer, see GetComposer.org:

It's important to realize that these vendor libraries are not actually part of your repository. Instead, they're simply un-tracked files that are downloaded into the vendor/. But since all the information needed to download these files is saved in composer.json and composer.lock (which are stored in the repository), any other developer can use the project, run composer install, and download the exact same set of vendor libraries. This means that you're controlling exactly what each vendor library looks like, without needing to actually commit them to your repository.

So, whenever a developer uses your project, they should run the composer install script to ensure that all of the needed vendor libraries are downloaded.

Since Symfony is just a group of third-party libraries and third-party libraries are entirely controlled through composer.json and composer.lock, upgrading Symfony means simply upgrading each of these files to match their state in the latest Symfony Standard Edition.

Of course, if you've added new entries to composer.json, be sure to replace only the original parts (i.e. be sure not to also delete any of your custom entries).

Решения хостинга субверсии

Гаибольшей разницей между Git и SVN является то, что субверсия требует работы центрального хранилища. Для этого у вас есть несколько решений:

  • Самостоятельный хостинг: создайте ваше собственное хранилище и получайте доступ к нему через систему файлов или сеть. Чтобы получить помощь в этой задаче, вы можете прочитать Контроль версий с субверсией.
  • Сторонний хостинг: существует множество серьёзных решений в виде свободных хостирнгов, таких как GitHub, Google code, SourceForge или Gna. Некоторые из них также предлагают хостинг Git.

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.