En Subversion, ¿cómo debo configurar una nueva versión principal de mi aplicación?

10

Estoy a punto de comenzar a trabajar en una nueva versión (versión 4) de mi aplicación comercial. Yo uso Subversion.

Según sus experiencias, errores y éxitos, ¿cómo recomendaría que configure la nueva versión en Subversion?

Aquí hay algo de información: tengo la intención de seguir lanzando actualizaciones críticas en la versión 3 durante algún tiempo después del lanzamiento de la versión 4. Sin embargo, todo el desarrollo de nuevas características se realizará únicamente en la versión 4.

En caso de que sea relevante: soy un desarrollador en solitario de este producto, y es probable que siga siendo así.

EDITAR: conozco las etiquetas y ramas de SVN. Supongo que lo que necesito es una estrategia óptima para usar etiquetas y ramas en mi situación.

version-control svn

— Steve McLeod
fuente

8

Lo que quieres hacer es crear ramas . Es como suena una rama en su árbol fuente, generalmente una copia de su fuente cuando la libera. Te comprometerías en esta rama para las actualizaciones críticas y construirías la actualización desde esta rama.

En lo que se está comprometiendo en este momento sería en el trunky codificaría la versión 4 allí. Si se realizan cambios importantes en la versión 3, y le gustaría tenerlos en la versión 4, haría una fusión de la rama (v3) a la troncal (v4) para llevar los cambios a la troncal.

También puede ver las etiquetas , que son como ramas pero vinculadas a una única versión, generalmente la última revisión de una versión (o la primera).

— Karthik T
fuente

Mientras crea una rama de la versión anterior, también puede crear una etiqueta para cada actualización / lanzamiento que cree. De esta manera, tiene una rama con la que comprometerse y puede usar las etiquetas para crear cualquier versión anterior que haya realizado.

— Geerten

Las etiquetas IIRC en svn no necesariamente se vinculan a versiones individuales, de hecho, son idénticas a las ramas en todos menos intension

— jk.

En realidad, las ramas y las etiquetas son idénticas en la implementación, son esencialmente copias del código. Es solo en la convención que difieren, las etiquetas están destinadas a señalar una revisión particular, mientras que se supone que la rama es una ruta de desarrollo alternativa.

— Karthik T

3

Depende.

Puede mantener la versión 4 en el tronco y continuar desarrollando en V4. La versión 3 sería una rama, que actualizarías según sea necesario. El beneficio de este enfoque es que si se descubrió un problema crítico en V3 que también está en V4, podría hacer una simple fusión en el archivo (s) a través de las ramas.

La otra opción es crear un repositorio completamente nuevo para V4. Esto te dará un nuevo comienzo. La desventaja es que el historial de cambios se restablece y no podrá fusionar archivos a través de Subversion. Tendrá que usar un programa como Beyond Compare para fusionar los cambios.

Personalmente, me quedaría con el primer enfoque. Cree una rama V3 y mantenga el código y las actualizaciones en esta rama. El nuevo código V4 se puede desarrollar en el tronco.

— Chuck Conway
fuente

2

Encontré una excelente guía para esta situación :

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too.

— Steve McLeod
fuente

0

Lo que está preguntando es la estrategia de ramificación (y fusión) a utilizar. Así que toma el post de karthik t y tómalo como una receta.

Para algunos antecedentes, lea los siguientes recursos:

SVN Red Book para el diseño del repositorio (repositorios de proyectos individuales vs. repositorios)
Patrones de rama en su contexto, usará una rama de lanzamiento por versión principal
Software Configuration Management Patrones de la teoría base que se utiliza en Subversion (y todos los demás sistemas CM). Vea allí los patrones , especialmente la línea de lanzamiento allí.

— mliebelt
fuente