SVN - ¿Cómo interceptar y modificar o añadir archivos de pre-entrega?

Question

En primer lugar no estoy seguro de esto es posible, sin embargo necesito saber cómo se puede hacer y si no ¿por qué no?

Quiero crear una aplicación de C # que se ejecuta en el momento apropiado durante el proceso de confirmación de un depósito de la subversión (pre-commit creo) que luego añadir otro archivo que estar comprometidos.

Por ejemplo, puedo hacer cambios en Program.cs y Main.cs, pero no AssemblyInfo.cs. Quiero ser capaz de forzar un cambio en AssemblyInfo.cs o cualquier archivo para el caso.

Me escribió una aplicación de consola utilizando SharpSVN que disparó el post-commit, que luego se reemplaza un archivo, pero esto provocó un incremento en el número de revisión. Obviamente eso no es lo ideal.

Me encontré entonces SvnLookClient dentro SharpSVN que se ejecuta en pre-commit y han comenzado a escribir algo, pero un callejón sin salida cuando me di cuenta CopyFromPath no quiso decir lo que esperaba:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

Por otra parte, me conformaré con hacer esto fuera de C #, pero lo ideal es que me gustaría hacerlo en una aplicación de consola de C # para que yo también puedo decirle a mi servidor de repositorios para realizar otras tareas como correr en los scripts de base de datos, etc.

Answer 1

No se debe modificar la transacción durante un gancho-script. Usted puede rechazar el comprometerse con un mensaje ( stderr será enviado a la cliente), o hacerlo de una separada comprometerse en el post-commit.

[editar] Quiero aclarar ¿Por qué modificación de transacciones es una mala idea (SVN-técnico):

El cliente no sabe nada al respecto.

A excepción de "OK", "Error" y la salida stderr no hay ningún canal de retorno desde el servidor al cliente durante una confirmación.

Cuando el cliente se compromete a sus cambios, y se informa que es un éxito de la confirmación, que marca su estado de archivo y carpeta local para estar en sintonía con la versión del repositorio [xyz]. Cuando más tarde cambia algo, por ejemplo, añadir el archivo localmente, quiere confirmar esos cambios, pero luego ... Bueno, se puede tratar de saber lo que pasa, espero que algo a lo largo "checksum error" o "archivo ya añadido" . Dependiendo del tipo de los cambios que probablemente no tienen una mejor oportunidad de conseguir un trabajo de WC eliminando la carpeta y hacer una copia nueva de la parte dañada.

Esa fue la parte técnica. Ahora el lado del desarrollador: En primer lugar, los cambios de fijación de forma automática correctamente parece inteligente, pero se producirá un error, debido al simple hecho de que si la fuente sería pre-computable, no tendríamos que dejar que escribir por los desarrolladores. Usted quiere que sus desarrolladores hacer lo correcto.

Esto funciona mejor a través de la educación: tienen que saber lo que es lo correcto. Buenas medidas para conseguir que sepan algo es, adicional a la buena formación de edad de cualquier clase, dándoles retroalimentación.

Un error-mensaje del servidor SVN, un correo automatizado después de roto construye o unidad de pruebas, los resultados de una herramienta de análisis de código fuente estático, etc., puede también servir como una buena herramienta educativa.

Yo recomiendo usar continúa la integración y validación de la fuente de árboles allí. Esto tiene la ventaja de que un desarrollador no se bloquearán para cometer sus cambios después de un largo día de trabajo, pero todavía se sabe que el estado de la fuente de árboles.

Y, ahora acaba de adivinar lo que quiere tratar de conseguir: El lado servidor de origen-árbol siempre será "funcional". Entonces, el problema es que incluso con archivos de fijación automática, pre-commit pruebas unitarias, estilo de comprobación y cualquiera que sea, que, finalmente, todavía tiene que comprobar si el programa realmente funciona, por el sistema de pruebas de estilo antiguo. Así que, básicamente, que en realidad no se gana nada.

La tecnología puede apoyar los procesos, así herramientas pensadas apoyan tan bien que después de los procesos en realidad ayuda a los desarrolladores de ahorro de tiempo y hacer su flujo de trabajo más sencillo. Pero la tecnología por lo general no puede reemplazar los procesos, y no puede sustituir a la inteligencia humana (al menos, por ahora). [/ Editar]