Cuando un compromiso con el control de revisión requiere que un desarrollador cambie su propia configuración

Question

¿Cuál es el mejor método para notificar a otros desarrolladores cuando un cambio comprometido en el control de revisión requiere alguna acción adicional específica por parte del desarrollador obteniendo la actualización, p. ¿modificar un archivo de configuración local que no está en control de versión?

Actualmente estoy escribiendo en el mensaje de confirmación, pero parece que esto podría perderse fácilmente. ¿Algún sistema de control de revisión proporciona una mejor manera de hacer esto?

¿Cómo lo hacen otras personas o nunca debe haber cambios necesarios que estén fuera del control de revisión?

Estoy usando mercurial pero las respuestas de aquellos que usan otras formas de control de revisión también serían útiles.

Answer 1

en muy raras ocasiones los cambios necesarios que se fuera del control de revisión. Para los raros casos en que se encuentran, use el canal de comunicación habitual que tienen los desarrolladores (como la lista de correo o el canal IRC o algo similar). Cada proyecto multiproveedor necesita tal cosa de todos modos.

Answer 2

Sólo una idea, pero que podría tener el gatillo en base a un patrón en el mensaje del informe para enviar un mail con el mensaje de consignación a los desarrolladores

factible con hooks

Answer 3

Personalmente, utilizo 2 métodos:

1. la comunicación uno: Yo digo a otros desarrolladores de lo que son las manipulaciones que hacer para estar al día (correcto, pero a veces, pasar por alto algunos detalles .. ..)
2. el script: Hice un script update que se utiliza para gestionar la actualización de todas las partes de mi proyecto (diferentes directorios, diferentes repositorios, control de versiones diferentes ...), en este script pongo cada operación necesaria para mantener un repositorio correcto (lo uso para repositorios svn y git).

Answer 4

con Git, lo que podría do (aunque no es realmente allí para ese escenario) es utilizar un filter driver, a condición de que su compromiso incluye cambios para un archivo con un recognizable content (el filtro doesn' t tiene un nombre o ruta del archivo).

Un controlador de filtro es:

• declaró en una .gitattributes archivos (significado, al contrario de ganchos o desencadenantes, puede distribuir fácilmente)
• unida a una mancha y una clara secuencia de comandos (también versionada, la mancha que se activa en commit.
• puede, en el compromiso, desencadena la acción automática que necesite.

Una vez más, el punto es no utilizar ganchos (que no se pueden replicar fácilmente entre los repos), y utilizar un mecanismo que se puede versionar y clonar.

Answer 5

Para los archivos donde cada desarrollador necesita realizar cambios locales (como cadenas de conexión de bases de datos, etc.) Me gusta mantener una plantilla como un archivo rastreado, algo así como localconfig.template.En sus scripts de compilación/inicio puede tener una lógica como esta:

if not exists localconfig then 
    copy localconfig.template to localconfig 
else 
    if localconfig.template is newer than localconfig 
    print a big ugly warning about maybe needing to update