¿Pueden Git o Mercurial pasar por el repository local e ir directamente al central?

Usando Git o Mercurial, si el directory de trabajo es de 1GB, entonces el repository local tendrá otros 1GB (como mínimo) y residirá normalmente en el mismo disco duro. Y luego cuando se lo envía a un repository central, habrá otro 1GB.

¿Se puede configurar Git o Mercurial para usar solo un directory de trabajo y luego un repository central, sin tener 3 copys de estos datos de 1GB?

(en realidad, cuando el repository central también se update , entonces hay 4 copys de los mismos datos … ¿se puede networkingucir? En el escenario SVN, cuando hay 5 usuarios, entonces habrá 6 GB de datos en total. Control, entonces habrá 12GB de datos?)

Actualización: es extraño. Solo traté de ver un proyecto que cloné usando Mercurial: el directory de trabajo que no incluye la carpeta .hg es de 126MB, pero la carpeta .hg es de 239MB. Y es un nuevo clon … ¿es porque mi nuevo repository en realidad contiene todo el historial / revisiones, por eso es el doble del tamaño del directory de trabajo?

Git o Mercurial son sistemas de control de versiones distribuidos . Esto significa que cada pago y envío contiene la historia completa del proyecto. Al eludir esto se vencería el propósito de usar un DVCS (cada operación se puede hacer fuera de línea).

Pero, en general, Mercurial o Git tienen una relación de compression muy alta, a menudo mejor que svn incluso si almacenan toda la historia.

hg clone crea enlaces duros en filesystems Unix, por lo que solo los cambios introducidos por los nuevos sets de cambios utilizan espacio en el almacenamiento. Cuando no desee una copy de trabajo, puede actualizar el repository a la revisión 'nula', que consiste únicamente en el repository sin copy de trabajo.

Git también tiene la opción de repositorys simples y repositorys compartidos, pero nunca los probé.

Puedes hacer lo que estás pidiendo siempre y cuando tengas el sistema de files con el repository "central" montado y accesible localmente.

Desde cmd.exe:

 git --git-dir=Z:/path/to/git_repo_dir --work-tree=C:/path/to/checkout/root checkout master 

Y puede hacer esto para todas las cajas que desee, pero en realidad no es ideal. Es cierto que git no funciona tan bien en Windows como en Linux: la solución ideal es que cada clon tenga enlaces duros a los objects, por lo que solo se almacenan físicamente en el disco una vez, y luego cada clon puede verifique en una sucursal diferente, por lo que puede rastrear el desarrollo / testing / producción de una sola vez, por ejemplo.

Además, en lo que respecta a sus preocupaciones sobre el uso del disco, intente hacer git gc --aggressive --prune en uno de sus repositorys y ver si todavía está ocupando una gran cantidad de espacio. En mi experiencia, git es muy bueno para almacenar solo deltas binarys; lo he probado agregando un directory lleno de files MP3 a un repository y comprometiéndolos, cambiando las tags ID3, y luego confirmando los cambios, y antes de ejecutar git gc había claramente dos copys de cada MP3 en la carpeta .git, pero después de git gc el tamaño volvió a ser ligeramente más grande que el directory de trabajo original.