Truco
Este artículo específicamente es sobre Subversion, y se basa en los principios que se encuentran en Cómo crear y guardar un proyecto Symfony2 en git.
Una vez hayas leído Creando páginas en Symfony2 y te sientas cómodo usando Symfony, sin duda estarás listo para comenzar tu propio proyecto. El método preferido para gestionar proyectos Symfony2 es usando git, pero algunos prefieren usar Subversion ¡lo cual está completamente bien! En esta receta, aprenderás a gestionar tu proyecto usando svn en una forma similar a como se debe hacer con git.
Truco
Este es un método para dar seguimiento a tu proyecto Symfony2 en un repositorio de Subversion. Hay varias maneras de hacerlo y esta simplemente es una que funciona.
Para este artículo supondrás que el diseño de tu repositorio sigue la estructura generalizada estándar:
myproject/
branches/
tags/
trunk/
Truco
La mayoría del alojamiento de subversión debe seguir esta práctica estándar. Este es el diseño recomendado del Control de versiones con Subversion y el diseño utilizado por la mayoría del alojamiento gratuito (consulta Soluciones de alojamiento Subversion).
Para empezar, tendrás que descargar Symfony2 y obtener la configuración básica de Subversion:
Descarga la edición estándar de Symfony2 con o sin vendors.
Descomprime la distribución. Esto creará un directorio llamado Symfony con tu nueva estructura del proyecto, archivos de configuración, etc. Cámbiale el nombre a lo que quieras.
Copia el repositorio de Subversion que será el anfitrión de este proyecto. Digamos que está alojado en Google code y se llama miproyecto:
$ svn checkout http://myproject.googlecode.com/svn/trunk myproject
Copia los archivos del proyecto Symfony2 en el directorio de subversión:
$ mv Symfony/* myproject/
Ahora vamos a configurar las reglas de ignorar. No todo se debe almacenar en tu repositorio de Subversion. Algunos archivos (como el caché) se generan y otros (como la configuración de la base de datos) están destinados a ser personalizados en cada máquina. Este hace uso de la propiedad svn:ignore, de modo que los archivos específicos se pueden omitir.
$ 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)"
Ahora, puedes añadir los archivos faltantes y confirmar los cambios al proyecto:
$ svn add --force .
$ svn ci -m "add basic Symfony Standard 2.X.Y"
Copia app/config/parameters.yml a app/config/parameters.yml.dist. El archivo parameters.yml es ignorado por svn (ve arriba) para no comprometer la configuración específica de la máquina ya que la contraseña de la base de datos no se envía. Al crear el archivo parameters.yml.dist, los nuevos desarrolladores rápidamente pueden clonar el proyecto, copiar este archivo a parameters.yml, personalizarlo y empezar a desarrollar.
Por último, descarga todas las bibliotecas de otros proveedores ejecutando el composer. Para obtener más información, consulta Actualizando vendors.
Truco
Si confías en las versiones «dev», entonces, puedes utilizar git para instalar bibliotecas, puesto que no hay un archivo disponible para descargar.
En este punto, tienes un proyecto Symfony2 completamente operativo almacenado en tu repositorio de Subversion. Puedes comenzar a desarrollar confirmando tus cambios al repositorio de Subversion.
Puedes continuar, siguiendo el capítulo Creando páginas en Symfony2 para aprender más acerca de cómo configurar y desarrollar tu aplicación.
Truco
La edición estándar de Symfony2 viene con alguna funcionalidad de ejemplo. Para eliminar el código de ejemplo, sigue las instrucciones del artículo «Cómo eliminar el AcmeDemoBundle».
Cada proyecto Symfony utiliza una gran cantidad de bibliotecas "vendor" de terceros. De una u otra manera el objetivo es descargar estos archivos en tu directorio vendor/ y, de ser posible, darle una forma sensata para manejar la versión exacta que necesita cada uno.
De manera predeterminada, estas bibliotecas se descargan ejecutando el «descargador» binario, php composer.phar install. Este archivo composer.phar es parte de una biblioteca llamada Composer y puedes leer más acerca de su instalación en el capítulo Instalación.
El archivo composer.phar lee el archivo composer.json en la raíz de tu proyecto. Se trata de un archivo en formato JSON, que contiene una lista de cada uno de los paquetes externos que necesita, la versión a descargar y mucho más. El archivo composer.phar también lee el archivo composer.lock, el cual te permite fijar cada biblioteca a una versión exacta. De hecho, si existe un archivo composer.lock, las versiones que contiene tienen prioridad en composer.json. Para actualizar tus bibliotecas a nuevas versiones, ejecuta php composer.phar update.
Truco
Si quieres añadir un nuevo paquete a tu aplicación, modifica el archivo composer.json:
{
"require": {
...
"doctrine/doctrine-fixtures-bundle": "@dev"
}
}
y luego ejecuta la orden update para este paquete específico, es decir:
$ php composer.phar update doctrine/doctrine-fixtures-bundle
También puedes combinar ambos pasos en una sola orden:
$ php composer.phar require doctrine/doctrine-fixtures-bundle:@dev
Para obtener más información sobre Composer, consulta GetComposer.org:
Es importante tener en cuenta que estas bibliotecas de proveedores en realidad no son parte de tu repositorio. En cambio, simplemente son archivos sin seguimiento que se descargan en el directorio vendor/. Pero, como toda la información necesaria para descargar estos archivos se guarda en composer.json y composer.lock (los cuales se almacenan en el repositorio), cualquier otro desarrollador puede utilizar el proyecto, ejecutar php composer.phar install, y descargar exactamente el mismo sistema de bibliotecas de proveedores. Esto significa que estás controlando exactamente cada biblioteca de proveedores, sin tener que confirmar los cambios a tu repositorio realmente.
Por lo tanto, cada vez que un desarrollador utilice tu proyecto, tendrá que ejecutar el guión php composer.phar install para asegurarse de descargar todas las bibliotecas de proveedores necesarias.
La mayor diferencia entre git y svn es que Subversion necesita un repositorio central para trabajar. Entonces, tiene varias soluciones:
