El tamaño utilizado en el disco es diferente del ancho de banda utilizado para hacer un clon. Algunos sitios de alojamiento (como Bitbucket) muestran el tamaño en el disco para que sepa por adelantado cuánto espacio necesitará en su sistema antes de clonar. Pero puedo ver que Google Code no lo hace, por lo que no te ayudará aquí.
El Mercurial wire protocol no expone ningún comando que pueda indicarle cuán grande es un repositorio. Cuando haces un clon normal, el cliente no sabe por adelantado cuántos datos recibirá, solo recibe una secuencia de datos. Después de recibir el registro de cambios, el cliente conoce cuántos manifiestos y registros de archivos se esperan, pero no conoce el tamaño de ellos.
De hecho, es difícil para el servidor calcular la cantidad de datos que utilizará un clon: el ancho de banda de red utilizado es menor que el espacio en disco ya que la compresión utilizada es diferente (bzip2 vs gzip). Sin embargo, si usa --uncompressed
con su clon (que Google Code no es compatible), entonces hay un truco, vea debajo.
La única forma de saber cuánto ancho de banda utiliza un clon es hacer uno. Si usted tiene un clon ya se puede utilizar para simular hg bundle
un clon:
$ hg bundle --all my-bundle.hg
El tamaño del paquete le dirá la cantidad de datos que hay en el repositorio.
Un truco: Si Google Code hubiera sido compatible con hg clone --uncompressed
, ¡podría usarlo para conocer el tamaño de un repositorio remoto! Cuando usa --uncompressed
, el cliente le pide al servidor que envíe el contenido del directorio .hg/
tal como está, sin volver a comprimirlo con bzip2. Convenientemente, el servidor inicia la transmisión al decirle al cliente el tamaño del repositorio. Por lo tanto, puede iniciar dicho clon y luego cancelarlo (con Control-C) cuando su cliente haya impreso la línea que le indica el tamaño del repositorio.
Estoy muy interesado en la respuesta a esto para SVN, ya que estoy buscando tener que clonar un repositorio SVN de 10 + GB (determinado por svn list -R) con> 10000 revisiones usando Mercurial (hgsubversion) a través del Internet. –
@TimDelaney en su caso, probablemente sea mejor utilizar 'svnsync' y clonar desde ese repositorio localmente. Sólo una suposición sin embargo. –
@ Ry4an He pensado en hacer eso (y luego cambiar la URL al SVN ascendente). La desventaja es duplicar el espacio de almacenamiento (al menos temporalmente). Además, no tengo idea si obtendré alguna ventaja en los datos totales transferidos. Estoy configurando un repo de Hg para desarrolladores locales con sincronización bidireccional. Obtuve el flujo de trabajo determinado y probado para permitir que todos trabajen como lo harían normalmente con Hg (ramificación, combinación, etc.) con algunos ganchos para evitar la rotura accidental del flujo de trabajo (no se fusiona con la rama SVN ...). Va a ser ese clon inicial lo que será un dolor. ¿Lo consigo todo o solo un subconjunto? –