Les tronc/branches/étiquettes imbriqués sont-ils acceptables?

Question

Dans un récent projet intégré, nous avons utilisé la structure svn suivante:

project 
    branches 
    tags 
    trunk 
     electronics 
     software 
      branches 
      tags 
      trunk 

Comme vous pouvez le voir, il y a une des branches imbriquées/tags/répertoire trunk pour la partie logicielle. C'était assez pratique pour les développeurs de logiciels car ils pouvaient simplement travailler là sans se soucier du reste.

Cependant, il ne semble pas me droit, il pourrait être source de confusion en raison des multiples niveaux de ramification, et les personnes qui travaillent plus dans la hiérarchie peut être incommodés par toutes les ordures qu'ils doivent télécharger si elles extrayez de la Je pense donc à un dépôt de 1 tronc seul pour le prochain projet, et si les développeurs ne veulent pas les choses non-logiciels, ils peuvent simplement passer à project/trunk/software et se diriger vers project/branches/br-1234/software

Que pensez-vous des troncs imbriqués? Pros & contre s'il vous plaît! Question subsidiaire: Les branches/étiquettes doivent-elles toujours être des copies du tronc (ou d'une autre branche), ou est-il acceptable de faire une branche d'un sous-répertoire de tronc?

Answer 1

Les lignes de réseau imbriquées indiquent une collection de code avec un cycle de vie différent de celui du code parent. Je considérerais ces projets conceptuellement séparés. Notez également que votre référentiel peut avoir plusieurs projets de niveau supérieur, ce qui devrait réduire la maintenance d'un référentiel distinct pour chaque projet. Je considère l'utilisation de référentiels séparés lorsque j'ai besoin d'une configuration séparée au niveau du référentiel: accessibilité, protocole de transport, authentification/autorisation (bien que ceux-ci puissent être configurés dans un référentiel).

main_project 
    branches 
    tags 
    trunk 
     electronics 
software 
    branches 
    tags 
    trunk 

soit Ensuite, vous pouvez ajouter un dossier libs-main_project/trunk pour contenir une forme compilée de software, ou peut-être envisager d'utiliser une référence externe SVN pour pointer vers software/trunk de l'intérieur main_project/trunk.

Aussi "main_project" pourrait être mieux nommé "electronics", auquel cas vous supprimeriez le dossier "electronics" supplémentaire sous "trunk".

Answer 2

Je dirais certainement pas idéal - devient très confus très rapidement. Étant donné qu'il ne prend pas vraiment beaucoup d'espace de stockage pour créer des branches/tags, il n'y a pas vraiment de raison de se retrouver avec une structure comme celle-ci. Branche au niveau du projet seulement à mon humble avis.

Answer 3

Acceptable à Qui? Il n'y a pas de pape de subversion, et chaque organisation est libre de faire ce qui lui convient le mieux. La polyvalence de SVN qui vous donne cette liberté est une bonne chose.

Answer 4

La réponse à toutes vos questions: non.

Je suis un Abbott & envisager Costello « qui est sur la première » discussion: « Je fusionné au tronc » « Quel tronc? » "le tronc de la branche d'intégration" "Donc le coffre est à jour?" "Quel coffre?"

Les nouveaux membres de l'équipe auront du mal à s'adapter à un programme qui contredit leur expérience antérieure. Ils devront chercher de la documentation interne ou poser des questions sur quelque chose qui devrait être très simple.

De nombreux outils & Les IDE sont beaucoup plus onéreux à utiliser si une mise en page non standard est utilisée. Votre deuxième question concernant les sous-ensembles de branchement/marquage du tronc ou d'une branche est plus préoccupante. avec des subversions bon marché, il n'y a pas de gain sur l'espace ou le temps pour ramifier/marquer un sous-ensemble - et surtout votre svn: mergeinfo deviendra beaucoup moins utile si les gens branchent/tagent n'importe où mais de haut niveau.