Quelle est la différence entre l'enregistrement et le paiement?

Lorsque vous enseignez des cours SCM à des étudiants qui sont nouveaux dans la gestion de la configuration logicielle, il arrive qu'une question se pose comme " What's the difference between checkin and checkout?".

Et une variante de cela est que ces étudiants se confondent au sujet de ces concepts SCM (ils les comprennent comme l'inverse).

Alors, quel genre de métaphore pouvez-vous utiliser pour expliquer ce concept SCM crucial à un tel public?

Pour expliquer quelque chose à quelqu'un, essayez de le comparer à quelque chose qu'il connaît (espérons-le) déjà.

C'est pourquoi je réponds simplement à une telle question comme ceci:

Considérez cela comme une arrivée dans un lieu de séjour (un hôtel, un complexe, etc.):

• la toute première chose que vous faites (à votre arrivée) est de le faire checkin.
• la toute dernière chose que vous faites (lorsque vous partez) est de le faire checkout.

Un concept SCM similaire s'applique lorsque vous souhaitez appliquer des modifications aux composants logiciels ... sauf qu'il s'applique dans l'autre sens :

• la toute première chose que vous faites (quand vous commencez) est checkout(ou pensez-y comme l'emprunter).
• la toute dernière chose que vous faites (lorsque vous avez terminé) est checkin(ou pensez-y comme de la rendre).

Remarque : cela s'applique aux systèmes centralisés (tels que ceux utilisés dans les environnements mainframe ...). Dans des systèmes tels que git, le checkoutconcept " " a une signification complètement différente (ce qui est également la raison pour laquelle, dans ces systèmes, il n'y a guère de confusion entre les deux concepts).

Il est important de noter que les termes «checkin» et «checkout» ont des significations différentes selon le type de système SCM.

Les systèmes centralisés comme TFVC, Subversion et Clearcase utilisent des extractions "exclusives". C'est comme la métaphore d'emprunt du livre de Pierre, où un seul utilisateur peut avoir un fichier extrait à la fois.

Les systèmes distribués comme git ont une commande "checkout", mais cela signifie quelque chose de complètement différent. git checkoutest utilisé pour basculer entre les branches lorsque vous travaillez avec un référentiel local.

Pour les systèmes centralisés, pensez-y comme une bibliothèque technique. (pourrait être un bout d'imagination sur le fonctionnement de cette bibliothèque hypothétique ...)

Si vous êtes l'auteur d'un document, vous pouvez checkoutcopier la bibliothèque, apporter des modifications, la retourner check it back inà la bibliothèque pour que le monde la voie.

Cela peut devenir un problème si la bibliothèque a des copies numériques, et moi checkoutun document, quelqu'un d'autre aussi checks outun document, nous apportons tous les deux des modifications, il y aura un conflit (conflit de fusion) qui pourrait être difficile à résoudre. Quand alors le "correctif" initial pour cela est une checkoutfonctionnalité exclusive ...

Bien sûr, pour les grands projets, les chances d'un problème critique de conflit de fusion sont réduites (les gens travailleront sur différentes parties du système) donc checkout/ checkinn'est pas autant nécessaire. Et comme les systèmes distribués par conception nécessitent quelque peu une bonne fonctionnalité de fusion, ainsi que de nombreux autres avantages, ce concept n'existe pas vraiment dans git et d'autres DVCS

Avec le référentiel SCM comme sujet principal, alors '

• la caisse devient des changements sur le référentiel local ou distant (dans votre répertoire de travail local).
• l'archivage replace les modifications dans le référentiel local ou distant (à partir de votre répertoire de travail local).

• Checkout est un verrou exclusif sur la modification d'une branche d'objet dans un référentiel.
• Checkin est une version de verrouillage exclusif.

Il existe deux types de systèmes de contrôle de source en fonction de la plus petite unité de branchement.

1) Branchement par référentiel (CVS, SVN, GIT, Perforce, ... etc)

Dans les produits où vous branche l'ensemble du référentiel, la caisse sera généralement créer une ou des modifications à permettre à la branche locale (copie) de l'ensemble du référentiel. Dans ces produits, l' archivage est souvent inutilisé et fait partie de l' opération de validation , qui est à la fois l' extraction de la branche distante, l'application du correctif local et l' archivage de la branche distante en une seule opération. Vous ne consignez pas votre succursale locale car elle est définitivement récupérée. (Remarque: dans GIT, vous ne vous engagez pas sur une branche distante, vous y poussez votre commit local. Différence strictement syntaxique. )

2) Branchement par objet (ClearCase, AccuRev, Oracle ADE)

Dans les produits où vous branchez des objets individuels, comme des répertoires, des fichiers, etc. Le concept de retrait et d' archivage s'applique par objet par branche. Vous verrouillez l'objet pour le modifier avec checkout et le relâchez avec checkin . Dans ces produits, vous travaillez souvent sur une branche privée où les verrous n'empêchent personne de fonctionner et au moment de la fusion de votre branche locale dans une branche partagée, les objets sont également extraits sur la branche de partition (principale, principale, branche de fonctionnalité, etc. ) les conflits de fusion sont résolus et l'objet est archivé sur la branche partagée. Cela permet à plusieurs personnes de «valider» en même temps la branche partagée tant qu'elles ne modifient pas les mêmes objets.