2009-06-22 20 views
10

¿Cuál es una mejor práctica al configurar la subversión para usar ramas de proveedores? Nuestro repositorio está estructurado para proyectos individuales. Estamos usando subversion 1.6.2 y tortoiseSVN 1.6.3.Subversion Vendor Branches

Ejemplo estructura de carpetas:

Project1 
/tags 
/branches 
/trunk 

Project2 
/tags 
/branches 
/trunk 
  1. Dónde pondría carpeta que los vendedores y qué estructura debe tener?
  2. ¿Hay algún ejemplo que use el cliente tortoisesvn?

Respuesta

13

El manual de Subversion tiene una sección específica en Vendor Branches.

La idea básica es importar la versión actual, sin modificaciones, en el repositorio a través de un conjunto de carpetas que rastrean los cambios externos (solo los cambios externos, no sus modificaciones). Algo así como ".../repos/vendor/(software)/current". Luego bifurque de inmediato en ".../repos/vendor/(software)/(software-version)". A medida que salen nuevos lanzamientos, actualice el directorio "actual" y cree una nueva rama, como ".../repos/vendor/(software)/(próxima versión)". Esto le permite (y svn) hacer diffs en la fuente no modificada para llegar a lo que cambió externamente.

Para sus modificaciones en el software, bifurque la "(versión de software)" en su propio proyecto, algo así como ".../repos/(mi-proyecto)/trunk/(software)". Cuando actualice a la siguiente versión de la fuente de terceros, dígale a svn que combine la diferencia entre "(versión de software)" y "(próxima versión)" en una copia de trabajo de "trunk/(software)". Esto lleva todos los cambios externos al tronco, mejorando cuidadosamente la fuente del proyecto. Ramifique y etiquete el proyecto como siempre.

La distribución de Subversion incluye un script de Perl llamado "svn_load_dirs.pl", que puede ayudar al actualizar el proyecto de "proveedor". Descubre los archivos eliminados, agregados y renombrados y modifica su copia de trabajo de, por ejemplo, "(actual)", según corresponda.

+11

Ese maldito libro SVN tiene todo, ¿no? – Travis

0

Lo que dices es cierto, pero en la práctica verás un gran problema.

Al importar el proyecto de proveedor a su repositorio de subversión (y suponer que el proyecto del proveedor es grande, digamos como apache httpd 2.2) encontrará que es imposible importar las propiedades svn: ignorar en cada directorio debido a el hecho de que no existe ninguna herramienta de exportación que pueda hacer esto solo con acceso a la interfaz WebDAV (hay una herramienta de administración svn que puede exportar accesorios svn pero requiere acceso directo en el repositorio del proveedor).

Así que cuando importa un proyecto de proveedor tendrá que exportar primero el original del repositorio de svn del proveedor y después de importar los archivos en su svn, configurará los apoyos svn manualmente para cada directorio dentro del proyecto. Un método muy llamativo, pero es el único si realmente desea modificar el proyecto del proveedor y mantenerse al día con sus modificaciones.

+0

Por cierto, el script Perl llamado "svn_load_dirs.pl "es totalmente ineficiente ya que no sabe acerca de los apoyos de svn. Después de ejecutar un script de este tipo, tendrá que configurar manualmente svn props y commit de nuevo y solo después de este paso puede crear la copia de la versión de la etiqueta. ? – gigiduru

3

Para cualquier persona que venga a esto en una fecha posterior, vale la pena saber que a partir de la versión SVN 1.8, el método documentado para manejar las ramas de proveedores descrito en la respuesta de James a esta pregunta ha cambiado.

En el momento de escribir este documento, la nueva documentación para esto aún se está finalizando, para verla en la sección Sucursales del proveedor del Capítulo 4 del Libro SVN: http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html. Tenga en cuenta que las advertencias en la parte superior de esa página indican que la documentación está en progreso.