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

14

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?

terminology scm

— Pierre.Vriens
source

checkout = verrouiller; checkin = déverrouiller; Vous prenez un verrou exclusif pour éditer l'objet en question sur la branche sur laquelle vous effectuez l'opération.

— Jiri Klouda

8

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).

— Pierre.Vriens
source

Peut-être que le code ressemble plus à un livre de bibliothèque qu'à une chambre d'hôtel?

— Toby Speight

C'est une réponse plutôt naïve et profane. J'ai travaillé pendant une décennie sur les composants internes des systèmes de contrôle de source, j'ai donc ajouté une réponse un peu plus approfondie à votre question.

— Jiri Klouda

6

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.

— Dave Swersky
source

Bon point Dave sur les systèmes distribués! En fait, c'est aussi pourquoi moi-même au début (quand j'ai entendu parler de GIT pour la première fois) était terriblement confus. Pour ne pas invalider votre réponse (en adaptant ma question), j'ai affiné ma propre réponse pour la clarifier un peu.

— Pierre.Vriens

Je dois préciser: git checkout est utilisé pour extraire des objets du référentiel. Cela peut être une branche ou un seul fichier.

— Dave Swersky

4

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

— Thymine
source

C'est une autre façon de voir les choses. Bien que d'après mon expérience, je ne pense pas que ce soit une bonne idée d'ajouter également des choses comme "conflits" et "fusion" (s'ils ne se sentent même pas encore à l'aise avec le paiement et l'enregistrement).

— Pierre.Vriens

Juste, je l'ai ajouté parce que c'est la principale raison pour laquelle je pense à la caisse / à l'enregistrement. Et l'impression que saisir un concept est extrêmement difficile si vous ne savez pas à quoi ce concept est réellement utile.

— Thymine

2

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).

— hlovdal
source

Merci pour cette réponse aussi . C'est en effet une façon de l'expliquer, même si je me demande encore si vous pouvez penser à une sorte de "métaphore" (comme dans ma question). Par exemple, pour l'expliquer à quelqu'un que vous enseigneriez, qui n'a même pas la moindre idée de ce qu'est réellement un référentiel local ou distant .

— Pierre.Vriens

Certes, s'ils n'ont aucune idée de ce qu'est un référentiel, alors essayer d'enseigner l'archivage et le retrait n'aura aucun sens. Maintenant, pour une métaphore du contrôle des sources en général, vous pouvez la comparer à la comptabilité financière / tenue de livres. Il suit fondamentalement les modifications de la valeur des actifs. Vous enregistrez soit des changements individuels individuels soit des groupes de changements (par exemple "Voyage de A à B" plutôt que ticket de taxi + ticket de bus + billet de train + ...) bien que pas de grands groupes (par exemple "Toutes les dépenses le lundi"). De même, un référentiel garde une trace des modifications du code source, des groupes individuels ou pas trop grands.

— hlovdal

1

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.

— Jiri Klouda
source

Salut Jiri, merci pour ta réponse. Pour ces 2 types que vous avez mentionnés, je serais d'accord. Mais dans les outils SCM dans le monde du mainframe (d'où vient mon expérience), on ne prend pas en compte le "verrouillage" ... Pouvez-vous penser à un moyen d'ajouter un 3ème type à votre réponse?

— Pierre.Vriens

Pouvez-vous me donner un exemple de produit qui ne rentre pas dans ces deux catégories? Je peux soit vous dire lequel des 2 il correspond ou ajouter un troisième, s'il y en a vraiment un. Checkout et checkin sont des opérations sur une branche donnant et libérant le droit de la modifier. Le partitionnement sur les branches d'un produit (référentiel entier ou objets individuels) est donc naturel pour cette question. Je ne sais pas s'il y a quelque chose entre les deux, quel serait-il? La ramification des sous-arbres comme dans Perforce et Subgit est essentiellement la première catégorie. Lock est juste un nom différent pour un «droit exclusif».

— Jiri Klouda

BTW La métaphore de la bibliothèque, comme mentionné précédemment, est vraiment bonne. Lorsque vous extrayez un livre, vous obtenez un droit exclusif sur celui-ci. Vous l'emportez chez vous et vous en faites à votre guise. Lisez-le ou même griffonnez des notes dans les marges et personne d'autre ne peut modifier le livre pendant que vous l'avez extrait. Comme supprimer certaines de ses pages ou mettre en évidence certaines lignes. Lorsque vous archivez le livre, les gens peuvent le lire à la bibliothèque, où l'œil vigilant du bibliothécaire ne permet aucune modification (vandalisme) ou le consulter et le rapporter à la maison. Il sérialise les modifications apportées à ce livre.

— Jiri Klouda

Pour continuer l'analogie, dans une branche différente de la bibliothèque, le même livre peut être là avec des modifications différentes ou entièrement inchangé ou pas du tout. Quelqu'un d'autre peut le vérifier en même temps (c'est-à-dire que le paiement s'effectue par succursale). Maintenant l'auteur d'origine travaille sur la 2e édition, une branche principale pour ainsi dire. Il pouvait lire les notes de plusieurs branches, les fusionner, vérifier la branche principale et enregistrer une 2e édition. Chaque branche de bibliothèque actualisera sa copie en achetant une 2e édition. Ils peuvent défausser la 1ère ou copier des notes encore utiles des marges vers la nouvelle édition.

— Jiri Klouda