Dans Subversion, comment dois-je configurer une nouvelle version majeure de mon application?

10

Je suis sur le point de commencer à travailler sur une nouvelle version (version 4) de mon application commerciale. J'utilise Subversion.

Sur la base de vos expériences, erreurs et succès, comment recommanderiez-vous que je configure la nouvelle version dans Subversion?

Voici quelques informations: j'ai l'intention de continuer à publier des mises à jour critiques dans la version 3 pendant un certain temps après la sortie de la version 4. Cependant, tout développement de nouvelles fonctionnalités sera uniquement dans la version 4.

Au cas où cela serait pertinent: je suis développeur solo sur ce produit, et cela devrait rester le cas.

EDIT: Je connais les balises et les branches de SVN. Je suppose que j'ai besoin d'une stratégie optimale pour utiliser des balises et des branches dans ma situation.

version-control svn

— Steve McLeod
source

8

Ce que vous voulez faire, c'est créer des succursales . Il ressemble à une branche de votre arbre source, généralement une copie de votre source lorsque vous la libérez. Vous vous engagez dans cette branche pour les mises à jour critiques et générez la mise à jour à partir de cette branche.

Ce que vous vous engagez en ce moment serait le trunket vous coderiez la version 4 là-dedans. Si des modifications majeures sont validées dans la version 3 et que vous souhaitez les avoir dans la version 4, vous feriez une fusion de la branche (v3) vers le tronc (v4) pour apporter les modifications au tronc.

Vous pouvez également consulter les balises , qui sont comme des branches mais qui pointent vers une seule version, généralement la dernière révision d'une version (ou la première).

— Karthik T
source

Lors de la création d'une branche de la version précédente, vous pouvez également créer une balise pour chaque mise à jour / version que vous créez. De cette façon, vous avez une branche à laquelle vous vous engagez et vous pouvez utiliser les balises pour créer n'importe quelle version précédente que vous avez créée.

— Geerten

Les balises IIRC dans svn ne sont pas nécessairement liées à des versions uniques, elles sont en fait identiques aux branches dans tous sauf intension

— jk.

En fait, les branches et les balises sont identiques dans la mise en œuvre, ce sont essentiellement des copies du code. Ce n'est que par convention qu'ils diffèrent, les balises sont destinées à pointer vers une révision particulière, tandis que la branche est censée être une voie de développement alternative.

— Karthik T

3

Ça dépend.

Vous pouvez conserver la version 4 dans le coffre et continuer à développer sur V4. La version 3 serait une branche que vous mettriez à jour au besoin. L'avantage de cette approche est que si un problème critique a été découvert dans V3 qui l'est également dans V4, vous pouvez effectuer une simple fusion sur le ou les fichiers entre les branches.

L'autre option consiste à créer un référentiel entièrement nouveau pour V4. Cela vous donnera un nouveau départ. L'inconvénient est que l'historique des modifications est réinitialisé et vous ne pourrez pas fusionner de fichiers via Subversion. Vous devrez utiliser un programme tel que Beyond Compare pour fusionner les modifications.

Personnellement, je m'en tiendrai à la première approche. Créez une branche V3 et conservez le code et les mises à jour dans cette branche. Le nouveau code V4 peut être développé dans le coffre.

— Chuck Conway
source

2

J'ai trouvé un excellent guide pour cette situation :

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
source

0

Ce que vous demandez, c'est la stratégie de branche (et de fusion) à utiliser. Alors prenez le poste de karthik t et prenez cela comme une recette.

Pour quelques informations, lisez les ressources suivantes:

Livre rouge SVN pour la mise en page du référentiel (référentiels à un ou plusieurs projets)
Modèles de branche dans votre contexte, vous utiliserez une branche de publication par version principale
Modèles de gestion de la configuration logicielle la théorie de base utilisée dans Subversion (et tous les autres systèmes CM). Voir les modèles , en particulier la ligne de sortie.

— mliebelt
source