Comment utiliser MKS Integrity (contrôle de code source) plus efficacement

Question

Nous utilisons MKS Integrity pour notre contrôle de source. Je n'ai aucun contrôle sur cela - je dois juste l'utiliser.

Quels sont les "pièges" que je devrais connaître et éviter? Et y a-t-il des choses intéressantes sur le logiciel qui me permettront de mieux l'utiliser?

J'ai déjà rencontré des cas où la structure arborescente du contrôle source ne correspond pas à celle de mon sandbox. Dans plus d'un cas, un fichier existe à deux endroits, et lorsque je me resynchronise, j'obtiens la version actuelle, puis une ancienne version l'écrase, puis elle n'est plus synchronisée. C'est un défi de trouver l'ancien fichier, car, bien sûr, la structure de l'arborescence ne correspond pas.

Answer 1

Juste découvert ce MKS gotcha: Il permet seulement une révision d'un membre d'avoir une étiquette spécifique à la fois.

Entré dans cette façon: Quelqu'un de notre équipe renommé une ressource pdf, en ajoutant _OLD au nom de fichier (il a fait plutôt que de le laisser tomber parce qu'il voulait qu'il soit encore partie de nos déploiements)

Puis il a ajouté la nouvelle version du pdf, en l'ajoutant à la même archive pour qu'il se connecte au graphique de l'historique des révisions existant. Maintenant, si vous regardez l'historique des révisions pour ce membre, vous verrez qu'il y a deux révisions du même membre utilisé par le même chemin de dev. Dans le cadre de notre processus de déploiement, nous vérifions les artefacts déployés, en appliquant des étiquettes aux membres pour spécifier la version dont ils font partie.

Depuis MKS applique uniquement une étiquette à une révision, quand je suis allé à examiner le point de contrôle, il semblait que le nouveau pdf n'a pas été inclus dans notre déploiement parce qu'il lui manquait l'étiquette

En outre, ÉVITER VISUAL STUDIO INTÉGRATION !!! Depuis son installation, plusieurs membres de mon équipe ont eu à faire face à de fréquents plantages visuels, et apparemment ses mécanismes de branchement dépendent de fonctionnalités qui n'ont pas d'équivalent dans la ligne de commande d'intégrité ou le client gui. Donc, si quelqu'un dans votre équipe utilise l'intégration visuelle de studio, à moins que les branches dans lesquelles ils travaillent aient été créées par l'intégration, elles ne fonctionneront pas. Donc, vous vous retrouverez coincé à faire des choses en studio visuel que Visual Studio fait lentement et mal, juste pour que les membres de l'équipe qui utilisent l'intégration puissent travailler avec.

Answer 2

J'ai utilisé Source Control depuis 1999. C'est assez fiable, nous n'avons jamais perdu l'historique des changements. Nous ne faisons rien de fantaisie avec les branches, donc je ne peux pas répondre à votre question. Je suppose que vous avez resynchronisé (F6) et mise à jour vers la tête (F7).

SI est construit sur une conception en ligne de commande. Vous pouvez obtenir des résultats plus cohérents si vous utilisez les versions de ligne de commande (pj.exe, etc.). La documentation n'est pas triviale.

Nous essayons de migrer vers Subversion, car MKS veut de l'argent ridicule pour sa dernière version entreprise.