tortoise - svn tutorial español

duplicar una subcarpeta entre dos repositorios SVN grabables (2)

Tengo una situación con la que intento lidiar con el servidor SVN de mi empresa. Mantenemos todo nuestro código importante en un servidor bloqueado (lo llamaremos el servidor "dev"). Hay algunos archivos que necesitan ser editados por usuarios fuera de la red corporativa, por lo que tenemos otro servidor SVN (el servidor "global") al que se puede acceder fuera del firewall y contiene copias de esos directorios que contienen los archivos necesarios externamente. Si es importante, la estructura de carpetas del servidor global es un subconjunto del servidor de desarrollo (es decir, solo se trata de unos pocos archivos / directorios seleccionados, pero todos tienen las mismas rutas relativas, etc.). He incluido una breve explicación de por qué intentamos hacer esto al final de la publicación si quieres leerlo, pero créanme, tiene que hacerse en dos servidores separados.

A primera vista, svnsync parece ideal para este trabajo, pero tiene el desafortunado problema de requerir que sea la única cosa que modifica el repositorio de destino. Obviamente, eso no funcionará ya que nuestro repositorio dev se usa mucho.

Me parece que hay dos soluciones, y ninguna de ellas es una buena solución. Espero que alguien me ayude a modificar uno de estos, o mejor aún, a ofrecer una alternativa.

Mi primera idea es usar externos en el servidor de desarrollo, pero esto tiene algunos problemas. Lo más notable es que un externo seguirá la revisión del encabezado (no queremos establecerlo en una revisión específica ya que eso vencería el punto), y por lo tanto, si sacamos versiones anteriores del dev repos, las definiciones externas seguirán señalando a la cabeza del repositorio global, en lugar de a lo que parecía el repo global a la edad de nuestra vieja revisión, por lo que no podremos recrear los lanzamientos antiguos simplemente revisando una revisión anterior.
La otra solución es tener un trabajo cron exportar periódicamente las últimas revisiones desde el repositorio global y superponer esos archivos modificados en una copia de trabajo del dev repos, y luego confirmar los cambios. Probablemente este paso de superposición y compromiso se realice utilizando el script svn_load_dirs.pl que viene con SVN. Idealmente, esto se haría como un enganche post-commit en el repositorio global, pero nuevamente por razones de firewall, el servidor global no puede acceder al servidor de desarrollo, por lo que debe ser realizado por una máquina dentro del firewall (probablemente la máquina del servidor dev mismo) . Este enfoque tiene los inconvenientes de: el servidor de desarrollo puede estar desactualizado por tanto tiempo como el intervalo en el trabajo de cron, y si alguien accidentalmente comete un cambio en el servidor de desarrollo, su cambio será pisoteado. (Por si fuera poco, si alguien puede inventar un método de sincronización bidireccional, ¡sería increíble!)

Actualmente me estoy inclinando por la opción 2 porque parece que me acerca lo más posible a lo que necesito, pero sigue siendo una mala opción. También es esencialmente lo que estamos haciendo actualmente, con un trabajo humano en lugar de cron. Mis disculpas por la larga publicación. Muchas gracias por cualquier ayuda que pueda brindar.

Explicación de por qué: Necesitamos que estos archivos compartidos existan en la jerarquía del directorio del servidor de desarrollo porque son una parte requerida de nuestro software, por lo que las compilaciones, pruebas, etc. deben tenerlos. No puedo exponer el servidor de desarrollo a través del firewall: he tratado de convencer a los poderes y fallé. He dejado muy claro a los tomadores de decisiones que tener dos servidores separados para esto no es cómo se pretende utilizar SVN y que probablemente haya problemas. Para ayudar a mitigar algunos de los problemas que hemos previsto, solo se podrá escribir en el servidor global. La copia de los archivos del servidor dev será conceptualmente de solo lectura (solo se modifica cuando los cambios se sincronizan desde el servidor global), pero no creo que pueda aplicar esa política de solo lectura con controles de acceso SVN porque algunos de los archivos esa estructura de directorio no va a existir en el repositorio global, y por lo tanto necesita ser editable en dev, por lo que no puedo hacer que la cosa solo se lea solo. La configuración de solo lectura por archivo parece no ser posible, ya que hay cientos y a menudo se agregan y eliminan.

Podría intentar configurar un proxy de escritura directa, de modo que todas las escrituras en su repositorio público se reenvíen automáticamente al servidor privado.

Nunca he hecho esto, pero aquí hay algo de documentación sobre el tema.

En lugar de complicarnos aquí en el control de la fuente, puede valer la pena dividir los dos repos (eliminando el código que vive en global de dev) y luego tener la compilación de compilaciones de consumo de desarrollo global. Dado que su gente interna podrá comprometerse con ambos, y tener el mismo código en vivo en ambos, siempre será difícil.

No mencionó las herramientas de idiomas involucradas ... por lo que es difícil saber cómo va a encajar. Piense en una construcción basada en la publicación global de los artefactos y luego en la construcción de soluciones globales para esa dependencia.

Una cosa que no mencionó en la alternativa 2, va a perder la pista de auditoría ya que el usuario que se compromete con global no será el usuario que se superpone y se compromete con el desarrollador.