Podczas nauczania zajęć SCM dla studentów, którzy nie znają się na oprogramowaniu do zarządzania konfiguracją oprogramowania, zdarza się, że pojawia się pytanie takie jak „ What's the difference between checkin and checkout?
”.
Odmiana polega na tym, że tacy uczniowie są zdezorientowani tymi koncepcjami SCM (rozumieją ich na odwrót).
Jakiego rodzaju metafory możesz użyć do wyjaśnienia tej kluczowej koncepcji SCM takim odbiorcom?
terminology
scm
Pierre.Vriens
źródło
źródło
Odpowiedzi:
Aby coś komuś wyjaśnić, spróbuj porównać to z czymś, co (mam nadzieję) już zna.
Dlatego właśnie odpowiadam na takie pytanie:
Uwaga : dotyczy to scentralizowanych systemów (takich jak te stosowane w środowiskach komputerów mainframe ...). W systemach takich jak git
checkout
koncepcja „ ” ma zupełnie inne znaczenie (co IMO również powoduje, że w tych systemach nie ma prawie żadnych wątpliwości co do obu koncepcji).źródło
Ważne jest, aby pamiętać, że terminy „zameldowanie” i „kasa” mają różne znaczenia w zależności od rodzaju systemu SCM.
Scentralizowane systemy, takie jak TFVC, Subversion i Clearcase, wykorzystują „ekskluzywne” kasy. To jest jak metafora pożyczania książek Pierre'a, w której tylko jeden użytkownik może pobrać plik jednocześnie.
Systemy rozproszone, takie jak git, mają polecenie „kasy”, ale oznacza to coś zupełnie innego.
git checkout
służy do przełączania między oddziałami podczas pracy z lokalnym repozytorium.źródło
W przypadku systemów scentralizowanych pomyśl o tym jak o bibliotece technicznej. (może to być wyobraźnia, jak funkcjonuje ta hipotetyczna biblioteka ...)
Jeśli jesteś autorem dokumentu, możesz
checkout
skopiować bibliotekę, wprowadzić zmiany, zwrócić jącheck it back in
do biblioteki, aby świat mógł ją zobaczyć.Może to stać się problemem, jeśli biblioteka ma kopie cyfrowe, a ja
checkout
dokument, ktoś inny równieżchecks out
dokument, oboje wprowadzamy zmiany, wystąpi konflikt (konflikt scalania), który może być trudny do rozwiązania. Kiedy zatem początkowa „poprawka” w tym celu ma wyłącznącheckout
funkcjonalność ...Oczywiście w przypadku dużych projektów szanse na krytyczny problem konfliktu scalania są zmniejszone (ludzie będą pracować nad różnymi częściami systemu), więc
checkout
/checkin
nie jest ono potrzebne tak bardzo. A ponieważ rozproszone systemy z założenia wymagają dobrej funkcjonalności scalania, a także wielu innych korzyści, ta koncepcja tak naprawdę nie istnieje w Git i innych DVCSźródło
Z repozytorium SCM jako głównym tematem, a następnie „
źródło
Istnieją dwa rodzaje systemów kontroli źródła w zależności od najmniejszej jednostki rozgałęzienia.
1) Oddziaływanie na repozytorium (CVS, SVN, GIT, Perforce, ... itd.)
W produktach, w których rozgałęzia się całe repozytorium, kasa zwykle tworzy albo włącza modyfikacje do lokalnego oddziału (kopii) całego repozytorium. W tych produktach rejestrowanie jest często nieużywane i staje się częścią operacji zatwierdzania , która jest jednocześnie kasowaniem zdalnego oddziału, zastosowaniem lokalnej poprawki i rejestrowaniem zdalnego oddziału w jednej operacji. Nie zameldujesz się w lokalnym oddziale, ponieważ jest on na stałe wyrejestrowany. (Uwaga: w GIT nie zatwierdzasz zdalnej gałęzi, wpychasz do niej lokalne zatwierdzenie. Ściśle różnica składniowa. )
2) Rozgałęzienia dla poszczególnych obiektów (ClearCase, AccuRev, Oracle ADE)
W produktach, w których rozgałęziasz pojedyncze obiekty, takie jak katalogi, pliki itp. Pojęcie pobierania i zameldowania dotyczy każdego obiektu na gałąź. Zablokujesz obiekt, aby go zmodyfikować przy kasie i zwolnisz przy kasowaniu . W tych produktach często pracujesz w oddziale prywatnym, w którym zamki nie blokują nikogo do działania, a podczas scalania oddziału lokalnego w oddziale współdzielonym obiekty są również sprawdzane w oddziale odłamka (główny, główny, gałąź funkcji itp. ) konflikty scalania są rozwiązywane, a obiekt jest sprawdzany we współdzielonej gałęzi. Umożliwia to wielu osobom jednoczesne „zatwierdzenie” do udostępnionego oddziału, o ile nie modyfikują tych samych obiektów.
źródło