发布于 2015-08-27 16:54:07 | 162 次阅读 | 评论: 0 | 来源: 网络整理
小技巧
This entry is specifically about Subversion, and based on principles found in How to Create and Store a Symfony Project in Git.
Once you’ve read through 创建页面 and become familiar with using Symfony, you’ll no-doubt be ready to start your own project. The preferred method to manage Symfony projects is using Git but some prefer to use Subversion which is totally fine!. In this cookbook article, you’ll learn how to manage your project using SVN in a similar manner you would do with Git.
小技巧
This is a method to tracking your Symfony project in a Subversion repository. There are several ways to do and this one is simply one that works.
For this article it’s assumed that your repository layout follows the widespread standard structure:
myproject/
branches/
tags/
trunk/
小技巧
Most Subversion hosting should follow this standard practice. This is the recommended layout in Version Control with Subversion and the layout used by most free hosting (see Subversion Hosting Solutions).
To get started, you’ll need to download Symfony and get the basic Subversion setup. First, download and get your Symfony project running by following the Installation chapter.
Once you have your new project directory and things are working, follow along with these steps:
Checkout the Subversion repository that will host this project. Suppose
it is hosted on Google code and called myproject:
$ svn checkout http://myproject.googlecode.com/svn/trunk myproject
Copy the Symfony project files in the Subversion folder:
$ mv Symfony/* myproject/
Now, set the ignore rules. Not everything should be stored in your Subversion
repository. Some files (like the cache) are generated and others (like
the database configuration) are meant to be customized on each machine.
This makes use of the svn:ignore property, so that specific files can
be ignored.
$ cd myproject/
$ svn add --depth=empty app app/cache app/logs app/config web
$ svn propset svn:ignore "vendor" .
$ svn propset svn:ignore "bootstrap*" app/
$ svn propset svn:ignore "parameters.yml" app/config/
$ svn propset svn:ignore "*" app/cache/
$ svn propset svn:ignore "*" app/logs/
$ svn propset svn:ignore "bundles" web
$ svn ci -m "commit basic Symfony ignore list (vendor, app/bootstrap*, app/config/parameters.yml, app/cache/*, app/logs/*, web/bundles)"
The rest of the files can now be added and committed to the project:
$ svn add --force .
$ svn ci -m "add basic Symfony Standard 2.X.Y"
That’s it! Since the app/config/parameters.yml file is ignored, you can
store machine-specific settings like database passwords here without committing
them. The parameters.yml.dist file is committed, but is not read by
Symfony. And by adding any new keys you need to both files, new developers
can quickly clone the project, copy this file to parameters.yml, customize
it, and start developing.
At this point, you have a fully-functional Symfony project stored in your Subversion repository. The development can start with commits in the Subversion repository.
You can continue to follow along with the 创建页面 chapter to learn more about how to configure and develop inside your application.
小技巧
The Symfony Standard Edition comes with some example functionality. To remove the sample code, follow the instructions in the “如何删除AcmeDemoBundle” article.
composer.json¶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 it in the Installation
chapter.
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.
小技巧
If you want to add a new package to your application, run the composer
require command:
$ 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.
The biggest difference between Git and SVN is that Subversion needs a central repository to work. You then have several solutions: