Subversion - marquage uniquement pour les versions, pas de branchement - svn, contrôle de version

Je suis un petit développeur qui s’engage dans un référentiel sur une base individuelle. Seulement, j’administrerai et contribuerai à un projet. C’est pourquoi j’ai 2 questions -

1. Est-il possible de simplifier mon flux de travail et de faire tout le développement actif dans tronc? Puis, à un moment donné, j’envisage une version (assez de corrections de bugs ou une nouvelle fonctionnalité) pour créer un marque avec le versioning sémantique et ensuite procéder à en faire une version publique?

Mots clés:

   v1.0.0 // Code is being used in production
v1.1.0 // Add some functionality
v1.2.0 // Add other new functionality
v1.2.1 // Fix bug

Flux de travail:

construire de nouvelles fonctionnalités dans le coffre jusqu'à la stabilité -> version du tag -> construire de nouvelles fonctionnalités dans le coffre jusqu'à la stabilité (répétition)

2. Cette approche est-elle judicieuse et y a-t-il des inconvénients? Je voudrais tester le code de tronc d’abord sur un serveur d’assurance / de test, créez un marque une fois que le code est satisfaisant, relâchez cette balise dans un environnement de production. Cette balise serait alors accompagnée d'un journal des modifications indiquant le numéro de révision.

Remarque: Après avoir lu des articles sur ce site et ceci par exemple http://svnbook.red-bean.com/en/1.7/svn.branchmerge.when.html - J'ai vu qu'aucune approche de branche ne peut être adoptée, étant donné les niveaux de complexité liés à la ramification et à la fusion.

Réponses:

Est-il possible de simplifier mon workflow

Oui

Cette approche est-elle sage

Non, voir ci-dessous

et y a-t-il des inconvénients?

Oui - vous aurez quelques ennuis avec correction de bogues dans les versions publiées (nécessitera quand même la fusion des branches) et | ou détection des erreurs de base de code connues dans le code du tronc