SVN: la mejor forma de compartir código común en proyectos

Question

Tengo varios proyectos de sitios web en un único repositorio, cada uno de los cuales tiene una copia de WordPress. Actualizar WordPress significa actualizar todas las carpetas de proyectos y mantener copias redundantes. Esto es útil para mis scripts rsync que sincronizan toda la carpeta. También me da copias locales totalmente operativas del sitio.

Existen varias maneras de mejorar esto y me gustaría obtener algunos comentarios. Estoy en Windows y recientemente migré a Subversion.

1. Crea enlaces simbólicos a los bits de WordPress en cada carpeta de sitio web. Esto se mantendrá en Subversion y Apache. ¿Alguna desventaja?
2. Tener una sola carpeta de WordPress y bifurcarla en las otras troncales de sitio web. Leí que las ramas son baratas y que se mantiene una sola copia, pero no estoy seguro de si se debe realizar una bifurcación en los troncos. Personalmente, creo que este es el mejor enfoque. ¿Hay alguna razón para evitar esto?
3. Por último, podría mantener la estructura actual y usar una secuencia de comandos para hacer copias en todas las carpetas de sitios web.

¿Cuál es el mejor enfoque y hay alguna solución alternativa?

Answer 1

Una opción sería separar los bits de WordPress en un repositorio separado (ya que no es realmente parte de sus proyectos, es algo que se usa para construirlos), y luego usar svn: externals para buscarlos en sus proyectos en las ubicaciones correctas.

Externals Definitions in the SVN book

Answer 2

Se podría añadir un puntero que svn:external definición a la WordPress repository o hacer su propia separada "a medida WordPress repositorio" con los complementos y personalizaciones que utiliza.

Answer 3

Tal vez estoy usando Subversion por el camino equivocado, pero nuestra estructura de carpetas se parece a la siguiente

tronco - Core - Mensajería - Aplicación de gran alcance estupenda # 1 - Aplicación de gran alcance estupenda # 2 - Aplicación Super Potente # 3

De modo que todas nuestras aplicaciones comparten los mismos componentes de Core y Messaging. El único inconveniente de esto es que cuando las personas se ramifican, obtienen todas las aplicaciones, pero eso es más una molestia que otra cosa.

Answer 4

A menudo me sucede reutilizando las mismas bibliotecas de clases para diferentes proyectos y en mi caso prefiero tener una copia separada - congelada para cada proyecto. La única razón es que no quiero romper proyectos en los que no he trabajado por un tiempo en caso de que una de las bibliotecas sea obsoleta. Sin embargo, si cada proyecto es parte de un tipo de proyecto principal en el que trabajas constantemente, es diferente.

Answer 5

Una forma mejor de hacer esto es extraer wordpress en una rama separada de su repositorio. Luego, introduzca un archivo de configuración en cada uno de sus sitios web que almacene la ruta a Wordpress. Puede agregar esta ubicación a su ruta de inclusión de php. Aquí está un diagrama:

Esto tiene un par de ventajas:

• Usted puede experimentar con varias versiones de Wordpress a la vez, para hacer pruebas y qué-no.Puede compartir estos entre todos los sitios web
• No tendrá que preocuparse de dónde está yendo wordpress. Incluir una biblioteca dentro de un proyecto suele ser complicado, pero este tipo de configuración facilita la colocación de las cosas en una ubicación común.
• No tiene que mantener varias versiones de la biblioteca, la actualización es mucho más fácil.

Answer 6

Tradicionalmente todo debería estar separado en SVN. Parece que está utilizando SVN como un medio para tomar código de diferentes áreas y unirlas.

Así que estás usando SVN como una herramienta de construcción. Es mejor:

• mantener sus plugins separan
• no almacenan wordpress sí en SVN, a menos que utilice una rama de proveedor
• cuando se necesita para tomar una aplicación específica con componentes específicos, el trabajo con una build-script.

Answer 7

Si ya está alojando todos los sitios juntos en un repositorio, svn: externals se puede utilizar para unir diferentes partes del mismo repositorio de varias maneras.

E.g. con un repositorio como

 
repo/site1 
repo/site2 
repo/commonPieces 

Puede introducir un "svn: externos" propiedad en la sitio1 y directorios site2 que dice "commonPieces url-a-repo/commonPieces".

Querrá evitar cualquier bucle de recursividad aquí obviamente. Pero esto tiene la ventaja de que todo está en el mismo repositorio y puede compartir el historial: puede hacer que las cosas que se están volviendo más comunes desde el sitio1 o el sitio2 se conviertan en commonPieces usando "svn copy".

comparar nuestra solución actual donde estoy trabajando - la migración de material de nuestros repositorios de proyectos independientes en un único repositorio también -separada "corelibraries" pierde la historia del desarrollo. Dado que comúnmente desarrollamos características para un proyecto y luego decide volver a usarlos, esta pérdida de la historia sucede mucho ...

---

Editar: vale la pena recordar que, si bien "svn update" en la sitio1 se actualizará automáticamente commonPieces con esta propiedad "svn: externals" en su lugar, un "svn commit" en el sitio1 no mostrará cosas que han cambiado en site1/commonPieces. Tendrá que hacer dos commits por separado, uno del sitio1 y otro de site1/commonPieces.

Answer 8

¿Cuál es el mejor enfoque y hay alguna solución alternativa?

no ir fuera de tema, pero le sugiero que tome una mirada a git. hacemos este tipo de cosas día a día de cartuchos, y es una brisa.

FYI - migrado de SVN hace aproximadamente 2 años debido a este tipo de problemas.