Nous utilisons ClearCase sur mon lieu de travail. Une partie de notre processus standard Lorsque le code est fusionné dans la branche principale (coffre) consiste à éradiquer complètement toutes les versions des branches de développement et d'intégration. Parce que cela élimine tous les commentaires d'enregistrement qui s'est passé avec ces versions, nos fichiers source doivent avoir un long commentaire de prologue identifiant chaque changement.
Quelques occasions, j'ai souligné que cela annule l'une des raisons fondamentales de à l'aide d'un système de contrôle de la version et indiquait qu'en supprimant les versions, il devient impossible de voir qui a travaillé à l'origine sur quelque chose, Lorsque des problèmes ont été introduits, etc. Les personnes en vérifiant dans de nouvelles versions ont appris à ne pas avoir la peine d'entrer dans un commentaire d'enregistrement car il va simplement être supprimé de toute façon.
La justification que j'ai entendue pour supprimer les anciennes versions est généralement venue à des raisons «de bien-être». Mes collègues plus expérimentés ont l'impression de supprimer ces anciennes branches rend les arbres de la version pour des fichiers "Nettoyant". Ils prétendent qu'il n'y a aucune raison de conserver ces anciennes versions une fois que cela a été fusionné à notre tronc. Ils sont également préoccupés par le fait que d'autres développeurs conservent accidentellement ces branches obsolètes de leur Voir les spécifications de configuration . Enfin, ils affirment que l'élimination de ces branches enregistre l'espace disque sur le serveur CM.
ai-je raison d'avoir un mauvais sentiment à ce sujet ou existe-t-il d'autres magasins de développement qui fonctionnent avec succès de cette manière? Si vous pensez également que c'est une mauvaise idée, quels autres arguments en faveur de la conservation des anciennes versions seraient-elles fournir? Si vous avez fonctionné avec succès avec ce type de processus, quel type de prestations avez-vous observées?
édité pour clarifier: Les versions précédentes du coffre sont toujours préservées. Ce sont les branches où les choses ont été créées ou modifiées qui sont supprimées.
8 Réponses :
Suppression des versions est incompréhensible pour moi. On dirait que vos collègues essaient d'utiliser l'utilisation de ClearCase plutôt que de fournir une documentation appropriée, un soutien et une formation sur ses capacités.
Malheureusement, j'ai aussi rencontré des situations très similaires. Lors du démarrage de futurs projets, vous devriez essayer de faire des arguments propres et clairs pour la façon dont vous croyez que le contrôle de la version devrait être effectué. Peut-être que si le processus commence par le projet est établi correctement, ils verront tous les avantages et les appliqueront à des projets futurs.
Cela n'a pas de sens pour moi pourquoi vous utiliseriez la version de la version si vous n'allez pas conserver les versions.
Le principal avantage du contrôle de la version, à mon avis, est la capacité de revenir à temps. Je me trouve constamment à vérifier les versions précédentes des fichiers pour déterminer pourquoi ou comment quelque chose a été changé.
Ceci est particulièrement pratique que les exigences évoluent et vous trouvez que vous avez vraiment besoin de ce code que vous avez écrit il y a trois mois.
Il n'y a pas d'avantages pour supprimer les informations de révision. Même des informations de révision sans checkin Commentaires est 1000X mieux que pas d'informations de révision.
L'affaire la plus convaincante pour maintenir les informations de révision (au-delevant la récupération de fichier) est que lorsque vous trouvez un bogue et un traçable à la vérification où le bogue a été introduit, il est généralement judicieux de regarder autour de vous pour des Checkins par le même utilisateur autour de le même temps. Le bug pourrait être plus étendu qu'il apparaît pour la première fois. Ne peut pas faire cela sans informations de révision.
Changer d'emploi. Vous vivrez plus longtemps. Travailler avec des programmeurs qui ne comprennent pas les avantages du contrôle de la version ne peuvent être bons pour votre santé en cours.
Vous avez déjà remarqué un gros problème: avec la suppression des commentaires de commettre, il n'y a pas d'enregistrement automatique de la façon dont le code doit être le moyen. Il n'y a pas non plus de moyen d'examiner l'historique de la façon dont le logiciel doit être le moyen: c'est une grosse bosse, avec de gros commentaires de prologues qui peuvent ou non être exacts.
fréquemment quand je rencontre du code qui a l'air étrange, je veux savoir comment il s'agissait d'être. Étant donné que nous utilisons Subversion, je peux utiliser "SVN blâme" pour trouver la révision de la ligne dans laquelle est apparu et la vérifie à partir de là. Cela conduira généralement à comprendre le but du code et à me donner un indice ce que je pourrais briser en le changeant. Il est également souvent utile de trouver quand une fonctionnalité a été ajoutée ou supprimée.
Bien que cela puisse sauver un peu d'espace, un bon VCS stockera Deltas et ne prendra donc pas tout ce que beaucoup d'espace supplémentaire (note: je ne sais pas si ClearCase est bon de cette manière). Entre-temps, les fichiers que vous utilisez sont enflés par les commentaires du prologue et probablement par code commenté ou compilé sous condition au cas où cela sera utile ultérieurement.
Comme quelqu'un qui avait l'habitude d'administrer un système VCS, il n'y a que deux raisons de supprimer quelque chose hors du système. L'une est si quelque chose s'est engagé, cela ne devrait pas être, et causer des problèmes (il peut être très important, par exemple - certaines personnes ont eu des problèmes lorsque quelqu'un a commis non seulement les fichiers source, mais tous les binaires), et l'autre est si C'est inapproprié (comme des informations confidentielles).
Non, je ne pense pas que les avantages l'emportent sur les coûts. Les coûts sont évidents (et bien couverts par les réponses existantes), donc je vais aborder les soi-disant avantages.
Si vous voulez un arborescence source "nettoyeur", il existe de nombreuses autres fonctionnalités qui n'impliquent pas de destruction d'informations. La plupart des systèmes de contrôle des sources peuvent placer des éléments dans un état supprimé qui est masqué à partir de l'UIS standard (à moins que vous n'allumiez pas d'options spéciales); appliquer des autorisations de lecture sur une base par point; Déplacez les objets dans une zone prédéfinie de l'arborescence (par exemple, un endroit appelé «vieux choses»); ou tout ce qui précède.
à ma connaissance, chaque système SCC suffisamment puissant pour prendre en charge les spécifications de visualisation personnalisés permet également aux administrateurs d'auditer et d'écraser ces paramètres.
code source n'est tout simplement pas si gros. surtout après avoir envisagé de compression + delta stockage. Ce n'est que dans quelques applications de niche où de grands fichiers binaires sont impliqués pourrais-je envisager une suppression permanente. (E.G., les studios de développement de jeux vont à travers une tonne d'œuvres d'art et de vidéo haute résolution.) Même ainsi, ma politique de rétention ne serait pas si coupante comme celle que vous décrivez. Je garderais des instantanés à des intervalles prédéfinis à la place. Dites: toutes les révisions de 2 semaines, puis quotidiennement pour les 2 semaines précédentes, hebdomadaires pendant quelques mois avant cela, puis mensuellement au début.
La ligne de fond, le temps de développement est vraiment frackin 'cher. Quelques minutes d'administration CC + quelques districtons supplémentaires dans le San ne se comparent même pas.
S'il y a une chose que vous ne faites pas avec ClearCase, c'est supprimer la version.
Jamais. (Presque jamais jamais de toute façon).
ClearCase est fortement basé sur Delta, ses bases de base peuvent être définies en mode incrémental et nécessiteront des versions précédentes pour obtenir leur contenu de contenu, et plus généralement, l'historique des fichiers est à quoi il s'agit. (et Historique des fonts: RMver supprimera tous les xhlinks, c'est-à-dire tous les hyperliens comme des informations de fusion)
Si vous voulez vraiment nettoyer l'historique: Les seuls cas où l'élimination de la version pourrait être justifiée serait:
ClearTool Lock -Obsolte est la bonne réponse.
Juste obsolètes les anciennes branches du coffre que vous ne voulez plus voir. C'est généralement plus que suffisant.
rmver pour les anciennes versions pourraient réellement économiser lieu). Tous les autres types de fichiers ne sauveront pas un lieu significatif en ayant leurs anciennes versions supprimées.
Heureusement, à cause de la façon dont ClearCase fusionne le travail, la suppression de la version "source" d'une fusion ne mange pas les versions suivant la version de destination d'une fusion.
@Mike: Dans la base CC, vous êtes correct (mais vous ne pourrez plus dire pourquoi ces lignes particulières apparaissent soudainement dans votre branche principale). Avec UCM ... c'est une autre histoire (mais l'OP n'utilise pas UCM)
Être capable de Blâme Quelqu'un pour un changement spécifique est souvent très utile. Une fois que toutes les modifications sont dans le coffre, toutes les informations sur qui ont écrit quoi et pourquoi il a fait cela est perdu. Être capable de montrer à quelqu'un qui "ici - tu as fait cela, il" est souvent très utile sur lui-même, même sans les commentaires de commettre.
Sans une historique de contrôle de la version Un outil de "débogage" très utile, de recherche de l'historique de bug (par bisection) pour trouver la première révision introduite Bug, est impossible. Lorsque vous trouvez un commit qui a introduit un bogue (certaines VCS fournissent une commande «SCM BISOCT» pour vous aider, même pour terminer l'automatisation si vous avez un test script), et vous avez suivi de bonnes pratiques de contrôle de la version de petit problème unique, bien décrit comme décrit , alors il est très facile de trouver où le bogue est.
Cela aurait-il pu être fait pour économiser de l'espace disque dur? C'est à propos de la seule raison pour laquelle je peux voir pour vouloir supprimer des versions plus anciennes car il y a le potentiel d'un bogue à venir et que quelqu'un peut vouloir tester cela contre les anciennes versions si possible.