version control - significado - ¿Cuál es un buen patrón de uso de Mercurial para esta configuración?
mercurial vs git (3)
Correcto. La única forma de que algo llegue a la red cerrada es a través de una unidad flash.
Tenemos dos desarrolladores en la misma red cerrada (ugh, estúpida), otro desarrollador a un par de minutos en auto, y un cuarto desarrollador a mitad de camino en todo el país. El correo electrónico, ftp y medios de eliminación son todos métodos posibles de transferencia para las personas que no están en la misma red.
Soy uno de los dos desarrolladores de redes cerrados, considérenos la ubicación "maestra".
¿Cuál es la mejor configuración / patrón de Mercurial para el grupo? ¿Cuál es la mejor manera de transmitir los cambios a / desde los desarrolladores remotos? Como estoy a cargo, calculé que tendría que mantener al menos un repositorio principal con otro repositorio local en el que pueda desarrollar. Cada otra persona solo debería necesitar un clon del maestro. ¿Es esto correcto? Supongo que esto también me hace responsable de la fusión?
Como puede ver, todavía estoy tratando de entender el control de versión distribuida. No creo que haya otra forma de hacer esto con la situación de conectividad.
Los parches son una solución simple y versátil.
Para moverse por grupos más grandes de cambios (especialmente cambios binarios y fusiones), Mercurial ofrece paquetes binarios. Un paquete es básicamente el material binario que se envía a la red cuando haces hg push , pero aquí se captura en un archivo.
Imaginemos que he obtenido un clon de alguna manera (mediante memoria USB, DVD, etc.). Llámalo contra upstream . Luego hago un segundo clon, lo llamo devel . Hago todo mi desarrollo en devel y hago muchos commits, merges, etc. Dado que Mercurial se distribuye, puedo hacer todo esto sin conexión.
Para ver qué conjuntos de cambios faltan en la upstream lo hago
% hg outgoing ../upstream
Cuando tengo algo que enviar, puedo usar
% hg bundle changes.hg ../upstream
para obtener un archivo comprimido binario que contenga los conjuntos de cambios, incluidos todos sus metadatos. Entonces puedo grabar este archivo en un CD y enviarlo por correo ...
El destinatario del paquete puede hacer
% hg incoming changes.hg
para ver la lista de cambios y
% hg pull changes.hg
para descomprimir y agregar los conjuntos de cambios a su repositorio. Lo más probable es que tenga que fusionarse: esto es exactamente como si hubiera sacado directamente de su repositorio a través de HTTP o SSH.
Tenga en cuenta que el repositorio en upstream solo se utiliza como una forma conveniente de recordar qué conjuntos de cambios ya se encuentran en el repositorio en sentido ascendente. También puede anotar el ID del conjunto de cambios y usar el hg bundle --base cuando se agrupa para especificar el conjunto de cambios base (común). Vea el hg help bundle o busque en la wiki .
Los usuarios que se encuentran fuera de la red pueden crear parches y / o usar el correo electrónico para enviar las actualizaciones al repositorio principal o a alguien, como usted, para fusionarlos. Las otras personas internas pueden tener copias locales, como usted mismo y fusionarse, pero si tiene estos parches fuera de la red, sería mejor que una persona los trate para que nadie se confunda, pero eso es algo que tendría que hacer. Considérese.
Sincronizando para el otro lado, crearías un parche y les enviarías un correo electrónico o un disco flash a los desarrolladores remotos para parchar su sistema. Necesitarás una buena comunicación en el equipo, estoy agradecido de que no estoy en tus zapatos.
Esas son mis únicas sugerencias, bueno, lo obvio, ¡obtenles una conexión VPN! Me encantaría saber cómo va, qué planes se estabilizan en un ritmo semanal, etcétera.