¿Cuáles son algunas de las mejores prácticas para mantener múltiples versiones de un proyecto?

Question

Tengo un proyecto en el que estamos implementando v1 y comenzando a trabajar en v2. Me temo que vamos a ver correcciones de errores y cambios de funciones menores a v1 en los próximos meses, algunos de los cuales vamos a tener que pasar a la versión 2, algunos de los cuales vamos a tener que mantener separar. (Necesitamos mantener el conjunto principal de características de v1, pero solucionemos cualquier error a medida que se encuentren.)

Estamos utilizando SVN por el momento. He considerado cambiar a Git, pero soy un poco reacio a cambiar las herramientas. Aparte de esa posibilidad, ¿cuáles son algunas estrategias generales y mejores prácticas para hacer que gestionar esta situación sea lo más fácil posible?

Actualización: todo el mundo sugiere que ramifique el código en Subversion. Eso fue tan obvio para mí que pensé que estaba implícito en la declaración "estamos usando SVN". Aparentemente no. :) Sin embargo, voy a ver Mercurial and Bazaar y Git. ¿Algo más?

Answer 1

Usando SVN, lo mejor que puede hacer es ramifican su repositorio:

• En el tronco, mantenga la versión más reciente - no necesariamente una cierta estabilidad.
• Siempre que necesite separar una nueva versión principal de allí, bifurque a, digamos, 2.0 y puede mantener tanto la última versión como las versiones estables en el mismo repositorio.
• Si encuentra cambios en la rama 2.0 que necesitan fusionarse en el tronco, puede hacerlo sin problemas.

Answer 2

Debe utilizar SVN para etiquetar el código v1. De esta forma, puede crear una rama separada del código para soportar correcciones a esa base de código.

Answer 3

¿Ha considerado ramificar su tronco y hacer el desarrollo de v2 en la segunda rama una vez que la rama v1 está congelada? Si corrige errores en la rama v2 que afectan a v1 y desea liberar una actualización/parche para v1, solo combine esos cambios específicos con la rama v1 de la rama v2.

Todo eso es perfectamente factible en SVN, pero es mucho más fácil hacer una gestión de sucursal con una herramienta como Mercurial o Git. No puedo decirle si definitivamente vale la pena cambiarlo o no, ya que no conozco su compañía o base de código, pero es algo a considerar si puede evitar que esta situación surja repetidamente en el futuro a medida que libera más versiones.

Answer 4

Para las diferentes versiones, la mejor práctica es almacenar las versiones nombradas en la subcarpeta "etiquetas". (Los documentos de SVN recomiendan que tenga una carpeta de troncales, etiquetas y ramas para cada proyecto).

Cada vez que suelte una versión, copie el tronco en la carpeta de etiquetas y asígnele un nombre. Esa versión puede seguir y correcciones de errores se pueden hacer por separado y fusionarse de ida y vuelta.

docs SVN en el diseño del repositorio:

http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html

Answer 5

estamos utilizando TFS, pero para su problema específico, la solución será bastante similar: crear una nueva rama.
[Dependiendo del entorno de la aplicación que esté utilizando, al parecer, no Microsoft]
Nos hemos beneficiado de TFS porque:

1. Usted puede hacer funde entre las ramas [fusiones sin fundamento]
2. se puede trabajar con elementos de trabajo, [ para rastrear errores]
3. Con el soporte de Sharepoint, puede tener documentos, los scripts de prueba pueden vivir juntos felizmente en un portal.
4. con scripts PowerShell, puede tener todas las noches automerges

Answer 6

Usando git puede utilizar el siguiente enfoque:

su repositorio git podría tener las siguientes ramas. Cada rama de revisión contiene una versión de función que debe mantenerse.

master     - version: 3.0.0 (latest release) 
    \ 
    dev     - version: 4.0.0 (next release) 
    |\ 
    | hotfix-1.x   - version: 1.0.1 (current hotfix 1.x) 
    \ 
    | hotfix-2.x   - version: 2.0.1 (current hotfix 2.x) 
    \ 
    hotfix-3.x   - version: 3.0.1 (current hotfix 3.x) 

Correcciones:

Corrección de errores se hacen en revisión-1.x y se fusionó "arriba" en la revisión-2.x y de allí a revisiones con 3.x.

revisión-1.x -> revisión-2.x -> revisión-3.x ...

Corrección de errores también puede ser portado usando el comando git cherry-pick-3 a partir de revisiones .x a hotfix-1.x (si es necesario). Con el comando cherry-pick es posible elegir un solo compromiso y aplicarlo en una rama diferente. Git también detectará archivos movidos y renombrados y aún aplicará el cambio correctamente.

También puede agregar ramas de liberación en paralelo a las ramas de su revisión para preparar las versiones en esas ramas (se omite en este ejemplo). Esto es útil cuando no desea bloquear las ramas de revisión para nuevas confirmaciones. Consulte gitflow si desea obtener más información sobre los detalles de las revisiones y las ramas de publicación.

lanzamientos

de funciones:

nuevas características se basan en la rama dev y se fusionaron nuevo en la rama dev una vez terminado. Se crea una nueva rama de revisión para cada nueva versión de función.

Pasos:

• fusionar los cambios de la rama revisión actual en dev
• ramas función de combinación de nuevo en dev
• Crear nueva rama de revisiones desde dev
• Liberación de nueva revisión rama
• Combinar nuevo en maestro

Notas:

Creo que la rama principal ya no es muy importante cuando se decide mantener sus ramas de revisión. Creo que el esquema común de gitflow funciona de esa manera que destruye las ramas de su revisión y libera las ramas una vez que termina. Sus lanzamientos deben ser etiquetados y, por lo tanto, accesibles.