Qual é a diferença entre check-in e check-out?

14

Ao dar aulas de SCM para alunos que são novos no Software Configuration Management, ocorre uma pergunta como " What's the difference between checkin and checkout?".

E uma variação disso é que esses estudantes ficam confusos sobre esses conceitos de SCM (eles os entendem como o contrário).

Então, que tipo de metáfora você pode usar para explicar esse conceito crucial de SCM para esse público?

terminology scm

— Pierre.Vriens
fonte

checkout = bloqueio; check-in = desbloquear; Você usa bloqueio exclusivo para editar o objeto em questão na ramificação na qual você executa a operação.

— Jiri Klouda 12/09

8

Para explicar algo a alguém, tente compará-lo a algo com o qual eles já estão (espero) familiarizados.

É por isso que eu apenas respondo a essa pergunta assim:

Pense nisso como chegar a um lugar para ficar (um hotel, um resort etc.):

a primeira coisa que você faz (quando chega) é checkin.

a última coisa que você faz (quando sai) é checkout.

Um conceito semelhante de SCM se aplica quando você deseja aplicar alterações aos componentes de software ... exceto que se aplica o contrário :

a primeira coisa que você faz (quando começa) é checkout(ou pensa nisso como pedir emprestado).

a última coisa que você faz (quando termina) é checkin(ou pensa nisso como devolvê-lo).

Nota : isso se aplica a sistemas centralizados (como os usados em ambientes de mainframe ...). Em sistemas como o " " git, o checkoutconceito " " tem um significado completamente diferente (pelo que a IMO também explica porque nesses sistemas quase não há confusão sobre os dois conceitos).

— Pierre.Vriens
fonte

Talvez o código seja mais um livro da biblioteca do que um quarto de hotel?

— precisa

Esta é uma resposta bastante ingênua e leiga. Eu trabalhei por uma década em sistemas internos de sistemas de controle de origem e adicionei uma resposta um pouco mais profunda à sua pergunta.

— Jiri Klouda 12/09

6

É importante observar que os termos "check-in" e "check-out" têm significados diferentes, dependendo do tipo de sistema SCM.

Sistemas centralizados como TFVC, Subversion e Clearcase usam caixas "exclusivas". É como a metáfora de empréstimo de livros de Pierre, em que apenas um usuário pode fazer o check-out de um arquivo por vez.

Sistemas distribuídos como o git têm um comando "checkout", mas significa algo completamente diferente. git checkouté usado para alternar entre ramificações ao trabalhar com um repositório local.

— Dave Swersky
fonte

Bom ponto Dave sobre os sistemas distribuídos! Na verdade, é também por isso que eu (a primeira vez que soube do GIT) fiquei terrivelmente confuso. Para não invalidar sua resposta (adaptando minha pergunta), refinei minha própria resposta para esclarecer um pouco.

— Pierre.Vriens

Devo esclarecer: o git checkout é usado para verificar objetos do repositório. Isso pode ser um ramo ou um único arquivo.

— Dave Swersky

4

Para sistemas centralizados, pense nisso como uma biblioteca técnica. (pode ser um pouco da imaginação de como essa hipotética biblioteca funciona ...)

Se você é o autor de um documento, poderá checkoutcopiar a biblioteca, fazer alterações, devolvê-lo check it back inà biblioteca para o mundo ver.

Isso pode se tornar um problema se a biblioteca tiver cópias digitais, e eu checkoutum documento, outra pessoa também checks outum documento, nós dois fizermos alterações, haverá um conflito (conflito de mesclagem) que pode ser difícil de resolver. Quando então a "correção" inicial para isso é uma checkoutfuncionalidade exclusiva ...

É claro que, para grandes projetos, as chances de um problema crítico de conflito de mesclagem são reduzidas (as pessoas estarão trabalhando em diferentes partes do sistema), portanto checkout/ checkinnão é necessário quase o mesmo. E como os sistemas distribuídos por design exigem uma boa funcionalidade de mesclagem, junto com muitos outros benefícios, esse conceito não existe realmente no git e em outros DVCS

— Timina
fonte

Essa é outra maneira de ver isso. Embora, na minha experiência, não seja uma boa idéia adicionar também coisas como "conflitos" e "mesclagem" (se elas ainda não se sentem confortáveis com check-out e check-in).

— Pierre.Vriens

Justo, eu o adicionei porque é a principal razão pela qual o checkout / check-in existe em que eu poderia pensar. E sentir que entender um conceito é extremamente difícil se você não souber para que esse conceito é realmente útil.

— Timina 02/03

2

Com o repositório SCM como assunto principal, então '

check-out está ficando mudanças fora do repositório local ou remoto (em seu diretório de trabalho local).
O check - in está colocando as alterações novamente no repositório local ou remoto (do diretório de trabalho local).

— hlovdal
fonte

Merci por esta resposta também . Essa é realmente uma maneira de explicar, embora eu ainda me pergunte se você consegue pensar em algum tipo de "metáfora" (como na minha pergunta). Por exemplo, para explicar a alguém que você ensinaria, que nem tem idéia do que é realmente um repositório local ou remoto .

— Pierre.Vriens

É verdade que, se eles não têm idéia do que um repositório está tentando ensinar, o check-in e o check-out não terão sentido. Agora, para uma metáfora do controle de origem em geral, você pode compará-la à contabilidade / contabilidade financeira. É fundamentalmente acompanhar as alterações no valor dos ativos. Você grava alterações individuais individuais ou grupos de alterações (por exemplo, "Viaje de A para B" em vez de passagem de táxi + passagem de ônibus + passagem de trem + ...), embora não sejam grupos muito grandes (por exemplo, "Todas as despesas na segunda-feira"). Da mesma forma, um repositório acompanha as alterações no código-fonte, grupos individuais ou não muito grandes.

— precisa saber é o seguinte

1

O checkout é um bloqueio exclusivo na modificação de uma ramificação de objeto em um repositório.

O check - in é um lançamento de bloqueio exclusivo.

Existem dois tipos de sistemas de controle de origem, dependendo da menor unidade de ramificação.

1) Por ramificação de repositório (CVS, SVN, GIT, Perforce, ... etc)

Nos produtos em que você ramifica todo o repositório, o checkout geralmente cria ou habilita modificações na ramificação local (cópia) de todo o repositório. Nesses produtos, o check - in geralmente não é utilizado e se torna parte da operação de confirmação , que é ao mesmo tempo check-out da filial remota, aplicação de patch local e check - in da filial remota em operação única. Você não faz check-in na sua filial local, pois esta é permanentemente retirada. (Nota: No GIT, você não se compromete com a ramificação remota, envia sua confirmação local a ela. Diferença estritamente sintática. )

2) Por ramificação de objeto (ClearCase, AccuRev, Oracle ADE)

Nos produtos em que você ramifica objetos individuais, como diretórios, arquivos etc. O conceito de check - out e check - in se aplica por objeto por ramo. Você bloqueará o objeto para modificá-lo no checkout e liberará no check - in . Nesses produtos, você costuma trabalhar em uma ramificação privada onde os bloqueios não impedem ninguém de trabalhar e, no momento da mesclagem de sua ramificação local em uma ramificação compartilhada, os objetos também são verificados na ramificação de fragmento (principal, mestre, ramificação de recurso etc.) ) conflitos de mesclagem são resolvidos e o objeto é verificado na ramificação compartilhada. Isso permite que várias pessoas "confirmem" ao mesmo tempo em ramificações compartilhadas, desde que não modifiquem os mesmos objetos.

— Jiri Klouda
fonte

Hey Jiri, merci pela sua resposta. Para os dois tipos que você mencionou, eu concordo. Mas nas ferramentas de SCM no mundo do mainframe (de onde minha experiência se origina), não se leva em consideração o "bloqueio" ... Você consegue pensar em uma maneira de adicionar um terceiro tipo à sua resposta?

— Pierre.Vriens

Você pode me dar um exemplo de produto que não se encaixa nessas duas categorias? Posso dizer qual dos dois se encaixa ou adicionar um terceiro, se houver realmente um. O check-out e o check-in são operações em uma filial que concede e libera o direito de modificá-lo. Portanto, particionar o que um produto ramifica (repositório inteiro ou objetos individuais) é natural para esta pergunta. Não sei se há algo no meio, o que seria? Ramificação de subárvores como em Perforce e Subgit é essencialmente a primeira categoria. Bloqueio é apenas um nome diferente para um 'direito exclusivo a'.

— Jiri Klouda

BTW A metáfora da biblioteca, como mencionado anteriormente, é realmente boa. Ao fazer o checkout de um livro, você recebe um direito exclusivo. Você leva para casa e faz o que quiser. Leia ou rabisque notas nas margens e ninguém mais pode modificar o livro enquanto você o faz o check-out. Como remover algumas de suas páginas ou destacar algumas linhas. Quando você faz o check-in do livro, as pessoas podem lê-lo na biblioteca, onde o olhar atento do bibliotecário não permite nenhuma modificação (vandalismo) ou o faz check-out e o leva para casa. Serializa as alterações nesse livro.

— Jiri Klouda 12/09

Para continuar a analogia, em uma ramificação diferente da biblioteca, o mesmo livro pode estar lá com diferentes modificações ou totalmente inalterado ou não. Outra pessoa pode verificar isso ao mesmo tempo (por exemplo, o checkout é por filial). Agora, o autor original trabalha na 2ª edição, um ramo principal, por assim dizer. Ele podia ler notas de vários ramos, fundi-los, fazer check-out do ramo mestre e fazer check-in na 2ª edição. Cada ramo da biblioteca atualiza sua cópia comprando uma 2ª edição. Eles podem descartar a 1ª ou copiar notas ainda úteis das margens para a nova edição.

— Jiri Klouda 13/09/18