Perforce Dev Branches - Sparse Branching vs. Private Branching

Question

Estoy buscando comentarios sobre las ventajas y desventajas de los métodos disponibles para crear ramas de desarrollo individuales en un depósito de Perforce. Si entiendo correctamente, hay dos formas de manejar esto. El primero es crear una rama privada, que es una copia completa de la rama en la que está trabajando. La rama se mantendría completamente independiente y aislaría completamente sus cambios de la rama objetivo.

El otro método que he escuchado recomendado es ramificación dispersa. Se describe en Practical Perforce (Capítulo 9, p.242). Esto crea una rama, pero solo con los archivos que necesitará editar. A continuación, superpone la vista de cliente de la rama de destino con esta vista de cliente de rama de desarrollo dispersa.

Ambos métodos requerirían que el programador realice algún trabajo de integración para obtener sus cambios en la rama de destino. El método de la rama privada parece que requeriría mucha más memoria adicional para crear una copia de la rama completa. Sin embargo, la documentación de Perforce indica que realiza una "copia diferida" en esta situación.

La integración también permite a Perforce realizar una "copia diferida" de los archivos. Cuando se bifurcan archivos , el servidor en realidad no contiene dos copias de los archivos: solo contiene el archivo de origen y un puntero en la base de datos registra el hecho de que se ha producido la bifurcación en el archivo de destino. Las copias flojas hacen que la bifurcación sea una operación de bajo costo; el servidor no tiene que hacer un seguimiento de las copias duplicadas de los archivos.

Esto hace que parezca que el método de rama dispersa solo agrega la posibilidad de error humano al proceso ya que, por ejemplo, el desarrollador puede comenzar a trabajar en un archivo que no agregaron a la rama Sparse y luego accidentalmente actualiza un cambio a la rama objetivo que rompe la construcción. Pero, la funcionalidad de ramificación dispersa existe por una razón. Cualquier comentario sobre por qué existe y por qué debería usarlo en una sucursal privada completa (o viceversa) sería muy apreciado.

Answer 1

Como ha señalado desde el espacio de la documentación no es realmente un problema. La velocidad es sin embargo. Sincronizar todo el árbol de desarrollo puede llevar mucho tiempo. La integración de vuelta también tomará un tiempo. Si solo necesita una rama del árbol, ambas operaciones son mucho más rápidas.

Puede haber un error humano, como ya dijiste, pero si creas un branchspec, puede ayudar a aliviar algunos de los posibles errores.

Answer 2

La velocidad de sincronización y el espacio en el disco del cliente son los problemas para crear sucursales completas (la copia diferida ayuda en el servidor, pero no en la red o el cliente). Sin embargo, me pareció más fácil de configurar y entender que tratar de crear una rama dispersa, por lo que las ramas completas son lo que terminamos usando.

Answer 3

Una buena situación para la cual la ramificación dispersa es adecuada es cuando tiene un producto complicado compuesto potencialmente por muchos módulos. Supongamos que la compilación lleva mucho tiempo para todo el sistema, y ​​tal vez la sincronización también demore un montón: muchos archivos de datos. Pero su desarrollo solo necesita modificar un pequeño subconjunto de la base de la fuente completa, tal vez un módulo o dos, posiblemente con algún código de vinculación "más arriba".

En este caso, hacer una rama dispersa puede tener mucho sentido. Significa que ya se ha sincronizado con la mayoría de las cosas, y probablemente ya se haya creado también. Pero debe tener cuidado de que los archivos que modifique se ramifiquen primero; de lo contrario, corre el riesgo de romper la línea principal. Ciertamente requiere más cuidado por parte del programador.

Otro caso donde la ramificación dispersa puede ser la única forma práctica de hacer un desarrollo ramificado es si es difícil tener más de una versión de su aplicación en una máquina de desarrollo. En este caso, sería complicado tener tanto una construcción principal como una construcción de desarrollo y funcionando una al lado de la otra. Obviamente no es ideal, pero algunos productos son así por necesidad o por historia.