¿Utiliza el control de versión con código no jerárquico?

Question

Estoy buscando poner una base de código que ejecute varios sitios web en control de versiones. Hay varias instancias de esta base de código que ejecuta sitios web en diferentes servidores virtuales.

El problema que estoy enfrentando es que cada una de estas instancias separadas de más o menos el mismo código tiene subdirectorios con funciones específicas del sitio. Pero parece que los sistemas de control de versiones quieren controlar toda la jerarquía de directorios.

Por ejemplo, cada instancia tiene el directorio

/www/smarty/libs/plugins/ 

Donde encontrará funciones específicas del lugar de Smarty. Cuando estemos listos para ponerlo en control de versiones, la carpeta /www sería la raíz.

Una opción es tener todas las funciones específicas del sitio en todos los sitios. No veo un problema en sí mismo, pero de alguna manera parece arquitectónicamente "incorrecto". Habría un montón de archivos que solo pertenecen a una implementación.

Otra opción es tener un repositorio separado para cada archivo específico del sitio dentro de la base de código. Pero parece que podría convertirse rápidamente en una pesadilla cuando se intentan implementar nuevos sitios correctamente.

¿Cuál es la mejor manera de hacerlo? El sistema de control de versiones que estamos viendo es subversión.

Answer 1

En general, los sistemas de control de fuente se deben utilizar para controlar fuente. No están en su mejor forma controlando por completo las jerarquías de archivos, los permisos y otras cosas relacionadas. Es mejor dejarlos a la configuración de implementación.

Qué tal tener cada uno de los proyectos y directorios que necesita representar una vez en el sistema de control de versiones. Luego, en un directorio separado (quizás llamado /build/), tenga los diversos diseños de configuración. Es posible que tenga un archivo ant que compila cada sitio, o maven. O puede usar herramientas como o Fabric para tener más control sobre cada implementación.

Answer 2

Creo que lo mejor sería crear un directorio de nivel superior en su repositorio para cada sitio (Sitio-01, Sitio-02, etc.) y dentro de esos directorios poner el árbol de fuentes. Luego puede verificar los proyectos por separado. Creo que es aceptable y algo estándar usar el mismo repositorio para todos los proyectos en los que su empresa está involucrada.

Mi terminología podría estar fuera de lugar, pero la idea fundamental es sólida, creo.

Answer 3

Las herramientas están hechas para ser flexible (por lo general), así que aquí están algunas sugerencias:

1. más VCS' le permiten ignorar los archivos y directorios a través de algún mecanismo (por ejemplo Mercurial .hg archivo ignoran), por lo tanto, debería poder orientar lo que desea/debería controlar en comparación con lo que no debería ser.

2. Separe los archivos/directorios en proyectos de recursos comunes y proyectos específicos del sitio y luego use un sistema de compilación para integrarlos para crear un paquete desplegable. El sistema de compilación puede ser tan simple como un script de shell o un marco más sofisticado. Si se trata de una integración realmente simple, el VCS puede tener algunas características básicas para unir bases (por ejemplo, subpositorios Mercuriales).

Answer 4

Con la subversión, usted podría tener un montón de repositorios:

• www estar en un repositorio general de
• plugins estar cada uno en un repositorio específico del sitio

Luego tienen copias de trabajo anidadas:

svn co http://www_repo www 
cd www/smarty/libs 
svn co http://foo_plugins_repo plugins 

Consejo: añadir a pluginssvn:ignore propiedad de www/smarty/libs

svn propset svn:ignore "plugins" www/smarty/libs 

ciertamente se podría hacer eso con git también (a través .gitignore), y probablemente con otros sistemas de control de versiones, pero yo no los conozco.

(alternativamente, puede omitir la parte de copia de trabajo anidada (que puede asustar a algunas personas) y echa un vistazo lado cosas al lado del otro, pero el uso de un enlace simbólico en lugar de smarty/libs/plugins, mientras ignore todavía pertenece)

Answer 5

Usted' Falta un paso de "compilación", que tomaría la fuente en control de fuente y crearía los paquetes de implementación para los diferentes sitios. Solo se necesita un paquete de origen, diferentes configuraciones de compilación crean los diferentes paquetes de implementación. No trates de poner directamente el conjunto de deplyoment en control de fuente, ¡no es la fuente!