Subversion: ¿Hay algo más rápido que "svnsync"?

De modo que tengo mi repository de subversión almacenado en alguna nube (por ejemplo, code.google.com) pero debido a varias razones necesito que mi código no sea público.

Decidí que necesitaba download todo el repository y migrar a mi propio server svn.

Así que fui a usar:

svnsync init DEST SRC svnsync sync DEST 

¡Y tomó aproximadamente 0.5 segundos para cada revisión del repository!

Afortunadamente, mi repo solo tuvo 200 revisiones … por lo tanto, un par de minutos para esperar. Pero, ¿qué pasa con los proyectos maduros que tienen 200,000 o 2,000,000 revisiones?

… 2e6 * 0.5 / 60/60/24 ~ ¡alnetworkingedor de 11 días!


¿Hay algo más rápido que "svnsync" para download su repository desde una nube?

Bueno, obviamente podrías respaldarlo tú mismo en el server y luego comprimirlo y downloadlo. O simplemente no puedes download todo el historial.

¿Pero cuál es el punto de esta pregunta? Es un poco académico, ya que tu problema está resuelto.

Tengo este mismo problema en mi colección de repositorys que tienen cientos de miles de revisiones. Así es como me las paso:

  1. Crear un repository vacío en el espejo.
  2. Crea un file de volcado gziped de mi repository. (mi sistema de copy de security ya lo hace) (nota: este paso tardó la noche en enviar mi repository gigante por el continente)
  3. scp (o su técnica favorita de copy remota de files), el file de volcado al server espejo.
  4. Cargue el repository, asegurándose de especificar --force-uuid .
  5. Configurar el revprops en la revisión 0. Acabo de tomar un repository en blanco configurado normalmente y miré su rev ​​0.

Ahora está listo para ejecutar svnsync en su server maestro. Esto continuará desde donde sea que lo dejó tu vertedero.

En el caso del OP, donde no tiene acceso de console al server svn, svnsync (que es esencialmente svn checkout desde la URL 1 combinado con svn commit a la URL 2) es tan bueno como lo que va a get.

Pero si tiene acceso al server, hay forms más rápidas que svnsync . Un buen método para build un mirror es usar svnadmin hotcopy para hacer la copy inicial del repository, luego usar el svnsync init --allow-non-empty option added in subversion 1.7 para convertirlo en un mirror. Esto también le da una copy de security de sus ganchos, etc. svnsync no lo hará.

Tenga en count que querrá mover su directory de hooks-original a hooks-original o algo así para que no sean utilizados por el espejo, especialmente si tiene un gancho post-commit en el repository original que llama a la svnsync sync .