Qual è la differenza tra check-in e check-out?

Quando si insegnano le classi SCM agli studenti che non hanno familiarità con la gestione della configurazione del software, capita che sorga una domanda come " What's the difference between checkin and checkout?".

E una variazione di ciò è che tali studenti si confondono su questi concetti di SCM (li capiscono come il contrario).

Quindi che tipo di metafora puoi usare per spiegare questo concetto cruciale di SCM a tale pubblico?

Per spiegare qualcosa a chiunque, prova a paragonarlo a qualcosa con cui (si spera) già conosce.

Ecco perché rispondo a una domanda del genere in questo modo:

Pensalo come arrivare in un posto dove stare (un hotel, un resort, ecc.):

• la prima cosa che fai (quando arrivi) è checkin.
• l' ultima cosa che fai (quando parti) è checkout.

Un concetto SCM simile si applica quando si desidera applicare le modifiche ai componenti software ... tranne che si applica il contrario :

• la prima cosa che fai (quando inizi) è checkout(o pensare a come prenderlo in prestito).
• l' ultima cosa che fai (quando finisci) è checkin(o pensare a come restituirlo).

Nota : questo vale per i sistemi centralizzati (come quelli utilizzati negli ambienti mainframe ...). In sistemi come git il " checkout" concetto ha un significato completamente diverso (che IMO è anche il motivo per cui in quei sistemi non c'è quasi nessuna confusione su entrambi i concetti).

È importante notare che i termini "checkin" e "checkout" hanno significati diversi a seconda del tipo di sistema SCM.

I sistemi centralizzati come TFVC, Subversion e Clearcase utilizzano checkout "esclusivi". Questo è come la metafora del prestito del libro di Pierre, in cui solo un utente può fare il check-out di un file alla volta.

I sistemi distribuiti come git hanno un comando "checkout", ma significa qualcosa di completamente diverso. git checkoutviene utilizzato per passare da una filiale all'altra quando si lavora con un repository locale.

Per i sistemi centralizzati, pensalo come una biblioteca tecnica. (potrebbe essere un tratto dell'immaginazione come funziona questa ipotetica biblioteca ...)

Se sei un autore di un documento, potresti checkoutcopiare la biblioteca, apportare modifiche, restituirlo check it back inalla biblioteca affinché il mondo possa vederlo.

Questo può diventare un problema se la biblioteca ha copie digitali e io checkoutun documento, qualcun altro anche checks outun documento, entrambi facciamo delle modifiche, ci sarà un conflitto (unisci conflitto) che potrebbe essere difficile da risolvere. Quando poi la "correzione" iniziale per questo è checkoutfunzionalità esclusiva ...

Naturalmente per i grandi progetti le probabilità di un problema critico di fusione conflitto è ridotto (persone lavoreranno su diverse parti del sistema) in modo da checkout/ checkinnon è necessaria quasi tanto. E poiché i sistemi distribuiti in base alla progettazione richiedono in qualche modo una buona funzionalità di unione, insieme a molti altri vantaggi, quel concetto non esiste davvero in Git e altri DVCS

Con il repository SCM come soggetto principale, quindi '

• checkout sta ottenendo cambiamenti fuori dal repository locale o remoto (nella directory di lavoro locale).
• il check-in sta rimettendo le modifiche nel repository locale o remoto (dalla directory di lavoro locale).

• Il checkout è un blocco esclusivo sulla modifica di un ramo di oggetto in un repository.
• Il check-in è una versione del blocco esclusivo.

Esistono due tipi di sistemi di controllo del codice sorgente in base alla più piccola unità di diramazione.

1) Branching per repository (CVS, SVN, GIT, Perforce, ... ecc.)

Nei prodotti in cui si ramifica l'intero repository, il checkout generalmente crea o abilita le modifiche alla filiale locale (copia) dell'intero repository. In questi prodotti, il check-in è spesso inutilizzato e diventa parte dell'operazione di commit , che è immediatamente checkout del ramo remoto, applicazione della patch locale e check-in del ramo remoto in un'unica operazione. Non si effettua il check-in nella propria filiale locale in quanto è permanentemente estratto. (Nota: in GIT non ti impegni a un ramo remoto, spingi il tuo commit locale ad esso. Differenza rigorosamente sintattica. )

2) Per ramificazione di oggetti (ClearCase, AccuRev, Oracle ADE)

Nei prodotti in cui si ramificano singoli oggetti, come directory, file, ecc. Il concetto di checkout e checkin si applica per oggetto per ramo. Bloccherai l'oggetto per modificarlo con il checkout e rilascialo con il check-in . In quei prodotti spesso lavori su un ramo privato in cui i blocchi non impediscono a nessuno di lavorare e al momento dell'unione del tuo ramo locale in un ramo condiviso, gli oggetti vengono anche estratti su ramo di frammenti (principale, principale, ramo di caratteristiche, ecc. ) i conflitti di unione vengono risolti e l'oggetto viene archiviato nel ramo condiviso. Ciò consente a più persone di "impegnarsi" contemporaneamente nel ramo condiviso purché non modifichino gli stessi oggetti.