Repositorio de la organización

Question

Cuando empecé a usar sistemas de control de versiones como CVS y SVN, Realmente no entendía los conceptos de la "tronco", la ramificación, la fusión y el etiquetado.Ahora estoy empezando a entender estos conceptos, y en realidad la importancia y el poder detrás de ellos.

Así que, estoy empezando a hacerlo correctamente.O eso creo...Esto es lo que entiendo hasta ahora:La última versión de/versión estable de su código debe sentarse en /trunk/, mientras que las versiones beta o filo de las versiones de sentarse en el interior del /ramas/ directorio de directorios diferentes para cada versión beta, y luego se fusionó en el maletero cuando suelte.

Es esta una opinión demasiado simplista de ver las cosas?Lo repositorio de diseños. ¿ustedes recomiendan?Si se hace una diferencia, yo estoy usando Subversion.

Answer 1

Ver a estas dos preguntas ASÍ que para más información:

• ¿Qué rama de la etiqueta y el tronco significa realmente?
• Subversion pregunta

Answer 2

Lo que yo hago normalmente vemos como un estándar es:

El tronco debe contener en su línea principal de desarrollo, su versión inestable.Usted debe crear la liberación de las ramas para sus lanzamientos.

Algo así como:

/tronco (aquí están desarrollando la versión 2.0) /ramas/RB-1.0 (esta es la versión de la rama de 1.0) /ramas/RB-1.5

Cuando usted encuentra un error en la 1.5, que arreglarlo en la RB de la rama y, a continuación, combinar con el tronco.

También recomiendo este libro.

Answer 3

Eric tiene una excelente serie de artículos sobre la Fuente de Control de uso y organizativas de las mejores prácticas.El capítulo 7 se refiere a las ramas (y sí, se recomienda que el /trunk/ y /ramas/ directorios que se sugieren).

Answer 4

He utilizado Forzosamente por un largo tiempo, y por lo que mi comentario puede ser un poco Perforce-centric, pero los principios básicos se aplican a cualquier sistema SCM software que tiene la mitad de decente de ramificación.Soy un firme creyente en el uso ramificada prácticas de desarrollo.Tengo un "principal" (también conocido como "principales") que representa la base de código a partir de ahora hasta la eternidad.El objetivo es que esta es, la mayoría del tiempo, estable y, si empujón vino de la verdad, se podría cortar un comunicado en cualquier momento que refleja el estado actual de la funcionalidad del sistema.Esos molestos tipos de ventas sigo preguntando....

La evolución suceder en las ramas que se bifurcan desde MAIN (normalmente - en ocasiones puede que desee rama a partir de una rama de dev).Integrar de MAIN a su dev ramas tan a menudo como usted puede, para evitar que las cosas divergentes demasiado, o puede, simplemente, presupuesto para una mayor integración período posterior.Sólo integrar el culo a patadas nueva característica PRINCIPAL cuando esté seguro de que va a salir en el próximo lanzamiento.

Por último, tiene una VERSIÓN de línea, que la opción de las diferentes ramas de diferentes versiones.Hay algunas opciones dependiendo del etiquetado de las capacidades de su software SCM y cómo las distintas mayor/menor revisiones son propensos a ser.Así que usted puede optar, por ejemplo, para una versión de la rama para cada punto de liberación, o sólo para un importante número de rev.Su kilometraje puede variar.

En general, la rama PRINCIPAL de la liberación tan tarde como sea posible.Correcciones de errores y cambios de última hora pueden ir directamente a la LIBERACIÓN para su posterior integración a la PRINCIPAL, o en PRINCIPAL para la integración inmediata copia de seguridad.No hay ninguna regla dura y rápida - hacer lo que mejor funciona.Sin embargo, si usted tiene cambios que puedan presentarse a PRINCIPAL (por ejemplo,a partir de una rama de dev, o "pequeños ajustes" por alguien en la PRINCIPAL), luego hacer el anterior.Depende de cómo trabaja su equipo, lo que a su liberación de los ciclos de etc.

E. g.Me gustaría tener algo como esto:

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...

Un proyecto no trivial probablemente tendrá un número de DEV ramas activas a la vez.Cuando el desarrollo se ha integrado en el PRINCIPAL para que ahora es parte del núcleo del proyecto, matar a la vieja rama de DEV tan pronto como pueda.Muchos ingenieros se tratará de una rama de DEV como su propio espacio personal, y reutilizar para diferentes características a lo largo del tiempo.Desalentar este.

Si, después de la liberación, tiene que corregir un error, a continuación, hacer que en la versión correspondiente de la rama.Si el error ha sido previamente fijado en el PRINCIPAL, a continuación, integrar a todos, a menos que el código ha cambiado mucho en PRINCIPAL de la revisión es diferente.

Lo que realmente diferencia a los codelines es el de las políticas que se utiliza para administrar ellos.Por ejemplo, ¿qué pruebas se hacen de ejecución, que las revisiones de pre/post de un cambio, ¿qué sucede si una acumulación de los descansos.Normalmente las políticas - y por lo tanto los gastos generales son los más fuertes en la liberación de las ramas, y las más débiles en DEV.Hay un artículo aquí que va a través de algunos escenarios, y enlaces a otras cosas útiles.

Por último, recomiendo ir con una estructura simple para empezar, y sólo introducir extra dev & release como sea necesario.

Espero que ayude, y no está diciendo-la-bleedin'-obvio demasiado.