Was ist der Unterschied zwischen Ein- und Auschecken?

Beim Unterrichten von SCM-Klassen an Schüler, die noch nicht mit Software Configuration Management vertraut sind, taucht möglicherweise die Frage " What's the difference between checkin and checkout?" auf.

Und eine Variation davon ist, dass solche Studenten über diese SCM-Konzepte verwirrt werden (sie verstehen sie als umgekehrt).

Welche Art von Metapher können Sie also verwenden, um einem solchen Publikum dieses entscheidende SCM-Konzept zu erklären?

Um jemandem etwas zu erklären, versuchen Sie, es mit etwas zu vergleichen, mit dem er (hoffentlich) bereits vertraut ist.

Deshalb beantworte ich solche Fragen einfach so:

Stellen Sie sich vor, Sie kommen an einer Unterkunft an (einem Hotel, einem Resort usw.):

• die sehr erste , was Sie tun (wenn Sie ankommen) ist checkin.
• die sehr letzte , was Sie tun (wenn Sie verlassen) ist checkout.

Ein ähnliches SCM-Konzept gilt, wenn Sie Änderungen an Softwarekomponenten vornehmen möchten ... mit der Ausnahme, dass es umgekehrt gilt :

• die sehr erste , was Sie tun (wenn Sie beginnen) ist checkout(oder denken Sie daran es wie Kreditaufnahme).
• die sehr letzte , was Sie tun (wenn Sie fertig sind ) ist checkin(oder denken Sie daran , wie es zurück zu geben).

Hinweis : Dies gilt für zentralisierte Systeme (wie sie in Mainframe-Umgebungen verwendet werden ...). In Systemen wie " " git hat das checkoutKonzept eine völlig andere Bedeutung (was IMO auch ist, warum in diesen Systemen kaum Verwirrung über beide Konzepte herrscht).

Es ist wichtig zu beachten, dass die Begriffe "Einchecken" und "Auschecken" je nach Typ des SCM-Systems unterschiedliche Bedeutungen haben.

Zentralisierte Systeme wie TFVC, Subversion und Clearcase verwenden "exklusive" Kassen. Dies ist wie bei Pierres Metapher für das Ausleihen von Büchern, bei der nur ein Benutzer eine Datei gleichzeitig auschecken kann.

Verteilte Systeme wie git haben einen "checkout" -Befehl, der jedoch etwas völlig anderes bedeutet. git checkoutwird verwendet, um bei der Arbeit mit einem lokalen Repository zwischen Zweigen zu wechseln.

Stellen Sie sich zentrale Systeme wie eine technische Bibliothek vor. (Könnte ein Stück der Vorstellungskraft sein, wie diese hypothetische Bibliothek funktioniert ...)

Wenn Sie ein Autor eines Dokuments sind, können Sie checkoutdie Bibliothek kopieren, Änderungen vornehmen und sie check it back inan die Bibliothek zurückgeben, damit die Welt sie sehen kann.

Dies kann zu einem Problem werden, wenn die Bibliothek über digitale Kopien verfügt und ich checkoutein Dokument, jemand anderes auch checks outein Dokument, wir beide Änderungen vornehmen. Es kommt zu einem Konflikt (Zusammenführungskonflikt), der möglicherweise schwierig zu lösen ist. Wann ist dann die erste "Korrektur" für diese exklusive checkoutFunktionalität ...

Natürlich für Großprojekte ist die Wahrscheinlichkeit für einen kritischen merge Konflikt Problem reduziert ( die Menschen auf den verschiedenen Teilen des Systems arbeiten werden) so checkout/ checkinist nicht annähernd so viel benötigt. Und da verteilte Systeme vom Design her neben vielen anderen Vorteilen eine gute Zusammenführungsfunktionalität erfordern, gibt es dieses Konzept in Git und anderen DVCS nicht wirklich

Mit dem SCM-Repository als Hauptthema dann '

• Kasse wird Änderungen immer aus der lokalen oder Remote - Repository (in Ihrem lokalen Arbeitsverzeichnis).
• Beim Einchecken werden die Änderungen wieder in das lokale oder Remote-Repository (aus Ihrem lokalen Arbeitsverzeichnis) übernommen.

• Checkout ist eine exklusive Sperre für das Ändern eines Objektzweigs in einem Repository.
• Das Einchecken ist eine Freigabe der exklusiven Sperre.

Abhängig von der kleinsten Verzweigungseinheit gibt es zwei Arten von Quellcodeverwaltungssystemen.

1) Verzweigung nach Repository (CVS, SVN, GIT, Perforce usw.)

In Produkten, in denen Sie das gesamte Repository verzweigen, werden durch das Auschecken normalerweise Änderungen an der lokalen Verzweigung (Kopie) des gesamten Repository erstellt oder aktiviert. In diesen Produkten checkin ist oft ungenutzt und wird zu einem Teil der Commit - Operation, die auf einmal Kasse entfernten Zweig, die lokalen Anwendung Patch und checkin im Einzelbetrieb des Fern Zweig. Sie checken Ihre lokale Filiale nicht ein, da sie permanent ausgecheckt ist. (Hinweis: In GIT verpflichten Sie sich nicht zur Remote-Verzweigung, sondern übertragen Ihr lokales Commit darauf. Strikter syntaktischer Unterschied. )

2) Pro Objekt Verzweigung (ClearCase, AccuRev, Oracle ADE)

In Produkten , bei denen man einzelne Objekte verzweigen, wie Verzeichnisse, Dateien usw. Das Konzept der Kasse und checkin gilt pro Objekt pro Zweig. Sie sperren das Objekt, um es mit checkout zu ändern, und geben es mit checkin frei . In diesen Produkten arbeiten Sie häufig in einem privaten Zweig, in dem Sperren niemanden daran hindern, zu arbeiten, und zum Zeitpunkt der Zusammenführung Ihres lokalen Zweigs in einen gemeinsam genutzten Zweig werden die Objekte auch in einem Shard - Zweig (Haupt -, Master -, Feature - Zweig usw.) Ausgecheckt ) Zusammenführungskonflikte werden gelöst und das Objekt wird in der gemeinsam genutzten Verzweigung eingecheckt . Auf diese Weise können mehrere Personen gleichzeitig einen Commit für einen freigegebenen Zweig ausführen, sofern sie nicht dieselben Objekte ändern.