¿La mejor manera de crear un SVN-Mirror?

Actualmente estoy buscando la mejor manera de configurar un espejo SVN. Actualmente veo tres posibilidades, todas con sus propios inconvenientes:

Tener un SVN post-commit-Hook que esté bloqueando y sincronizando a través de svnsync. El problema aquí es, obviamente, que la confirmación está bloqueando hasta que los datos se transfieren al espejo.
Tener un SVN post-commit-Hook que no se bloquee y se sincronice a través de svnsync. Aquí veo el siguiente problema, más sutil: Imagina que alguien registra un archivo GRANDE, y otra persona poco después registra un archivo pequeño. Debido a que el commit no es de bloqueo, dos procesos de svnsync podrían ejecutarse al mismo tiempo y el archivo pequeño podría superar al archivo BIG en el camino hacia el espejo (esto parece muy crítico e improbable, aunque en principio es posible). Su revisión cambiaría.
Sincronice como cada quince minutos con un cron-job. El mismo problema si una confirmación tarda más de 15 minutos y obviamente ese retraso de tiempo.

¿Olvidé una posibilidad? ¿Me equivoqué? ¿Algunas ideas? Gracias ya!

Quizás debería tener en cuenta que la segunda posibilidad es la sugerida por diferentes sitios web. Por ejemplo, ver http://www.kirkdesigns.co.uk/mirror-svn-repository-svnsync

svn

— roesslerj
fuente

Debido a que el commit no es de bloqueo, dos procesos de svnsync podrían ejecutarse al mismo tiempo y el archivo pequeño podría superar al archivo BIG en el camino hacia el espejo (esto parece muy crítico e improbable, aunque en principio es posible). Su revisión cambiaría. Esto no es posible, svnsync replica las confirmaciones a medida que se escriben en el repositorio. Siempre aparecerán en orden de revisión.

— Dave Cheney

Podría intentar un enfoque similar al que usamos en Atlassian

https://www.atlassian.com/blog/archives/subversion_replication_at_atla?_ga=2.217251286.1933127788.1517539727-1159165484.1517539727

descargo de responsabilidad: actualmente soy un empleado de Atlassian, pero no participé en la implementación de esta solución (solo mantenerla)

Como dije anteriormente en el comentario, svnsync, ejecutado desde un repositorio remoto se comporta de manera determinista. No puede aplicar conjuntos de cambios fuera de servicio. Entonces, el único problema que tiene al usar un repositorio remoto es la cantidad de retraso debido a la propagación del conjunto de cambios.

— Dave Cheney
fuente

+1 para la observación de que svnsync no puede salirse del orden, el único problema es la latencia potencial.

— Jim T

Tienes toda la razón ... Cometí un estúpido error de pensamiento. Entonces, el gancho simple y hermoso SVN post-commit debería hacerlo en la mayoría de los casos. En caso de que la latencia sea un problema, se puede echar un vistazo al artículo referenciado de Atlassian. ¡Muchas gracias!

— roesslerj 03 de

Solo tenga en cuenta que el enlace post commit bloqueará el committer hasta que el enlace se haya completado. No estoy seguro de lo que sucede si falla el enlace post commit, no creo que el commit se revierta, pero al menos será confuso.

— Dave Cheney

Bueno, al usar el enlace posterior a la confirmación, puede emitir un comando que regrese inmediatamente (por ejemplo, a través de 'comando &' en linux), sin bloqueo. Como el enlace es posterior a la confirmación, no puede revertir la confirmación. Si svnsync falla, la próxima svnsync tiene que sincronizar dos revisiones, lo que simplemente hace. El problema que ocurre aquí lo archivaría bajo el tema latencia.

— roesslerj