Numéro de révision Subversion sur plusieurs projets

StackOverflow https://stackoverflow.com/questions/15674

  •  08-06-2019
  •  | 
  •  

Question

Lorsque j'utilise Subversion (svn) pour le contrôle de code source avec plusieurs projets, j'ai remarqué que le numéro de révision augmente dans tous les répertoires de mes projets.Pour illustrer ma mise en page svn (en utilisant des noms de projets fictifs) : 

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

Lorsque j'effectue un commit sur le tronc du programme Ninja, disons que je comprends qu'il a été mis à jour vers la révision 7.Le lendemain, disons que j'apporte une petite modification à l'application Stealth et qu'elle revient sous la forme de la révision 8.

La question est la suivante : Est-il une pratique courante et acceptée, lors de la maintenance de plusieurs projets avec un seul serveur Subversion, d'augmenter le numéro de révision des projets non liés dans tous les projets ? Ou est-ce que je me trompe et devrais-je créer des référentiels individuels pour chaque projet ?Ou est-ce tout autre chose ?

MODIFIER: J'ai tardé à signaler une réponse car il était devenu clair qu'il y avait des raisons pour les deux approches, et même si cette question est arrivée en premier, j'aimerais souligner d'autres questions qui posent finalement la même question :

Dois-je stocker tous les projets dans un ou plusieurs référentiels ?

Un référentiel SVN ou plusieurs ?

Était-ce utile?

La solution

Je suis surpris que personne n'ait mentionné que cela soit discuté dans Version Control with Subversion, qui est disponible gratuitement en ligne, ici.

J'ai lu quelque chose sur le sujet il y a quelque temps et cela semble vraiment être une question de choix personnel, il existe un bon article de blog sur le sujet. ici.MODIFIER: Puisque le blog semble être en panne, (version archivée ici), voici ce que Mark Pippard avait à dire à ce sujet.

Ce sont quelques-uns des avantages de l’approche du référentiel unique.

  1. Administration simplifiée.Un ensemble de crochets à déployer.Un référentiel à sauvegarder.etc.
  2. Flexibilité des branches/étiquettes.Avec le code tout en un seul référentiel, il est plus facile de créer une branche ou une balise impliquant plusieurs projets.
  3. Déplacez le code facilement.Peut-être souhaitez-vous prendre une section de code d'un projet et l'utiliser dans un autre, ou la transformer en bibliothèque pour plusieurs projets.Il est facile de déplacer le code dans le même référentiel et de conserver l'historique du code au cours du processus.

Voici quelques-uns des inconvénients de l’approche à référentiel unique et des avantages de l’approche à référentiels multiples.

  1. Taille.Il peut être plus facile de gérer plusieurs petits référentiels plutôt qu'un seul grand.Par exemple, si vous abandonnez un projet, vous pouvez simplement archiver le référentiel sur un support, le supprimer du disque et libérer du stockage.Peut-être avez-vous besoin de vider/charger un référentiel pour une raison quelconque, par exemple pour profiter d'une nouvelle fonctionnalité de Subversion.C'est plus facile à faire et avec moins d'impact s'il s'agit d'un référentiel plus petit.Même si vous souhaitez éventuellement le faire sur tous vos référentiels, cela aura moins d'impact de les faire un par un, en supposant qu'il n'y ait pas un besoin urgent de les faire tous en même temps.
  2. Numéro de révision global.Même si cela ne devrait pas être un problème, certaines personnes le perçoivent comme un problème et n'aiment pas voir le numéro de révision avancer sur le référentiel et que les projets inactifs aient de grandes lacunes dans leur historique de révision.
  3. Contrôle d'accès.Bien que le mécanisme d'authentification de Subversion vous permette de restreindre l'accès à certaines parties du référentiel, il est toujours plus facile de le faire au niveau du référentiel.Si vous avez un projet auquel seules quelques personnes sélectionnées doivent accéder, cela est plus facile à faire avec un seul référentiel pour ce projet.
  4. Flexibilité administrative.Si vous disposez de plusieurs référentiels, il est alors plus facile d'implémenter différents scripts hook en fonction des besoins du référentiel/des projets.Si vous souhaitez des scripts hook uniformes, un seul référentiel pourrait être préférable, mais si chaque projet souhaite son propre style d'e-mail de validation, il est plus facile d'avoir ces projets dans des référentiels séparés.

Quand vous y réfléchissez vraiment, les numéros de révision dans un référentiel de projets multiples vont devenir élevés, mais vous n'allez pas en manquer.Gardez à l'esprit que vous pouvez afficher un historique sur un sous-répertoire et voir rapidement tous les numéros de révision relatifs à un projet.

Autres conseils

Je pense qu'il est fortement recommandé de créer des référentiels distincts pour chaque projet.Ne serait-ce que pour éviter le scénario dont vous parlez.

Avec le contrôle de version, en particulier Subversion, vous pouvez facilement extraire des éléments d'un référentiel dans une autre copie de travail, puis les remettre dans leurs référentiels respectifs.Cela vous permet de les garder clairement séparés et distincts tout en vous offrant une grande flexibilité.Une fois que vous êtes entré un peu plus dans SVN (je suppose que vous êtes nouveau), vous pouvez commencer à utiliser des hooks et je pourrais voir où cela pourrait devenir difficile avec votre configuration.Si les autorisations sont importantes pour vous, un référentiel unique peut s'avérer plus difficile que nécessaire.

De plus, si vous craignez que la configuration de chaque référentiel prenne beaucoup de temps, consultez la variable SVNParentPath pour le fichier de configuration Apache.(Encore une fois, je suppose que vous utilisez Apache.)

Cela est dû au fonctionnement de la subversion.Chaque révision est en réalité un instantané du référentiel identifié par ce numéro de révision.Si tous vos projets partagent un référentiel alors c'est inévitable.En règle générale, d'après mon expérience, vous configureriez des référentiels distincts pour des projets totalement indépendants.La réponse courte est non, vous ne faites rien de mal. C'est une question courante concernant la subversion, mais cela a du sens lorsque vous réfléchissez à la manière dont elle stocke les informations du référentiel.

Le numéro de révision ne devrait en réalité être qu’un identifiant pour une version particulière.Que ce soit séquentiel pour un projet ou non ne devrait pas avoir d'importance.Cela étant dit, je peux comprendre que ce soit loin d’être idéal.

La plupart des projets que j'ai rencontrés ont été configurés dans un seul référentiel et les identifiants de révision se comportent de cette manière.Je ne connais aucune option de configuration SVN pour modifier ce comportement, et à mon humble avis, la maintenance de plusieurs référentiels semble être une surcharge inutile.

Nous n'avons qu'un seul référentiel contenant tout, à peu près exactement comme votre exemple.

Je ne vois rien de mal à cela - la seule exigence concernant le numéro de révision est qu'il soit

  • Unique
  • Atomique
  • Plus grand qu'il ne l'était lors du dernier enregistrement.

En ce qui me concerne, peu importe qu'il augmente de 1 ou 50 à chaque commit.

@grom :

Ensuite, chaque fois que je démarre un nouveau projet, je lance simplement :

svnadmin create /var/www/svn/myproject

Je peux voir que cela fonctionne bien si vous n'avez que 1 ou 2 développeurs, mais que se passe-t-il si les personnes qui créent de nouveaux projets n'ont pas d'accès shell sur le serveur SVN pour pouvoir créer des répertoires sous /var/www ?

Il est recommandé d'utiliser un référentiel distinct par projet.Dans mon répertoire Apache conf.d, j'ai subversion.conf qui contient :

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

Ensuite, chaque fois que je démarre un nouveau projet, je lance simplement :

svnadmin create /var/www/svn/myproject

Hm, là où je travaille, nous avons tous nos projets dans le même référentiel.Je ne vois vraiment pas l'avantage de les séparer, cela ne crée-t-il pas simplement beaucoup de travail supplémentaire : créer de nouveaux référentiels, accorder l'accès aux personnes, etc. ?Je suppose que des référentiels séparés ont du sens si les projets ne sont absolument pas liés et que vous avez, par exemple, des clients externes qui doivent avoir accès au référentiel.

Sur mon lieu de travail, nous avons deux référentiels.Un avec un accès public en lecture et un pour tout le reste.J'en utiliserais un seul pour tout, mais nous avons besoin de droits d'accès différents pour les projets publics/privés.

Cela dit, personnellement, je ne vois pas le problème avec les numéros de révision qui augmentent à chaque mise à jour.Les numéros de révision pourraient ignorer les nombres premiers et pairs tout en continuant à faire ce qu'ils sont censés faire.Facilitez l’accès à une révision spécifique.

Si le changement des numéros de révision en fonction d'autres projets vous dérange, placez les projets dans des référentiels séparés.C'est la seule façon de rendre les numéros de révision indépendants.

Pour moi, la principale raison d'utiliser différents référentiels est de fournir un contrôle d'accès séparé pour les utilisateurs et/ou d'utiliser différents scripts hook.

Il est peut-être préférable de ne pas nécessairement créer un dépôt par « projet », mais plutôt un dépôt par « solution » (pour utiliser les termes de Visual Studio).Si vous avez un tas de "projets" dans différents dossiers mais qu'ils sont liés les uns aux autres, placez-les dans le même dépôt.

Je stocke un projet par référentiel, et comme un précédent commentateur sur ce question de subversion, je marque les projets partagés comme externes, afin qu'ils ne soient qu'une seule fois dans le contrôle de code source.

Je commence tout juste à ajouter un serveur de build CI (CruiseControl.NET), je vais donc devoir voir comment tout cela fonctionne, mais si mes scripts de build sont corrects, cela ne devrait pas poser de problème.

Mais à part l’apparence, c’est vraiment une question de préférence (à mon avis).

Lorsque vous réfléchissez vraiment, les numéros de révision d'un référentiel de projets multiples vont devenir élevés, mais vous n'allez pas s'épuiser.Gardez à l'esprit que vous pouvez voir une histoire sur un sous-répertoire et voir rapidement tous les numéros de révision qui concernent un projet.

En fait, si vous créez du code Microsoft et que vous utilisez les numéros de révision svn dans le cadre de votre chaîne de version, vous pourriez en manquer.Le compilateur Microsoft générera une erreur si une partie de la chaîne de version est supérieure à 65535....Dans notre cas, nous avons un référentiel massif à la révision 68876 et nous venons de heurter ce mur.

Un référentiel par projet.

Le commentaire de Steven Murawski sur CC.NET est intéressant.Je serais intéressé de savoir comment cela fonctionne si vous devez spécifier plusieurs référentiels de contrôle de source.

@Daniel Fone :La documentation SVN recommande un projet par référentiel, c'est donc certainement la façon dont les créateurs voulaient que cela se déroule.Comme vous pouvez avoir un serveur (Apache ou svnserve) qui gère plusieurs référentiels, je n'ai jamais rencontré de problème de surcharge.Avec Serveur VisualSVN, installer un serveur Apache et configurer plusieurs référentiels est un jeu d'enfant.

Je ne suis pas sûr que la documentation SVN recommande réellement un projet par référentiel.Ils parlent principalement des avantages et des inconvénients de chaque chemin.Il se trouve que j'utilise trois référentiels différents, un pour 7 ou 8 projets tous liés, ce qui rend très agréable de pouvoir envoyer des copies compatibles de tous les projets simplement en construisant à partir d'une révision (ou en vérifiant qu'ils sont compatibles en regardant aux numéros de révision sur chacun).Le deuxième référentiel contient un autre groupe de projets et de documents associés, tandis que le troisième est beaucoup plus petit.Cela nous permet de profiter du fait que les projets liés peuvent être gérés par un seul numéro de révision, mais que les projets non liés n'affectent pas leur référentiel.

Les numéros de révision n'ont aucune utilité sémantique.La seule chose est qu'ils sont dans un ordre séquentiel.Si vous sauvegardez votre projet et l'importez dans un autre référentiel, vos versions peuvent obtenir de nouveaux numéros de révision.Donc JAMAIS utilisez les numéros de révision pour marquer vos versions ou des éléments similaires.Créez des balises pour les versions (copies de la révision pertinente).

J'ai eu le même problème dans mon entreprise précédente, ils avaient environ 50 projets en cours d'exécution dans un seul référentiel et c'était un cauchemar de travailler sur les mêmes projets à cause du fait que lors des mises à jour de SVN, d'autres maudiraient... mdr...

Une chose que j'ai apprise et qui fonctionne toujours le mieux, One project One Repo... vous ne le regretterez jamais.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top