¿Cuál es la diferencia entre checkin y checkout?

14

Cuando se imparten clases de SCM a estudiantes que son nuevos en la Gestión de la configuración de software, sucede que surge una pregunta como " What's the difference between checkin and checkout?".

Y una variación de esto es que tales estudiantes se confunden acerca de estos conceptos de SCM (los entienden al revés).

Entonces, ¿qué tipo de metáfora puedes usar para explicar este concepto SCM crucial a tal audiencia?

terminology scm

— Pierre.Vriens
fuente

pago = bloqueo; checkin = desbloquear; Usted toma un bloqueo exclusivo para editar el objeto en cuestión en la rama en la que realiza la operación.

— Jiri Klouda

8

Para explicarle algo a alguien, intente compararlo con algo con lo que (con suerte) ya estén familiarizados.

Entonces es por eso que solo respondo tal pregunta así:

Piense en ello como llegar a un lugar para quedarse (un hotel, un resort, etc.):

lo primero que haces (cuando llegas) es hacerlo checkin.

lo último que haces (cuando te vas) es hacerlo checkout.

Un concepto SCM similar se aplica cuando desea aplicar cambios a componentes de software ... excepto que se aplica al revés :

lo primero que haces (cuando comienzas) es checkout(o pensar en ello como pedirlo prestado).

lo último que haces (cuando terminas) es checkin(o pensar en ello como devolverlo).

Nota : esto se aplica a los sistemas centralizados (como los utilizados en entornos de mainframe ...). En sistemas como git, el checkoutconcepto " " tiene un significado completamente diferente (lo cual es IMO también es la razón por la cual en esos sistemas casi no hay confusión sobre ambos conceptos).

— Pierre.Vriens
fuente

¿Quizás el código se parece más a un libro de biblioteca que a una habitación de hotel?

— Toby Speight

Esta es una respuesta bastante ingenua, laica. He trabajado durante una década en los componentes internos de los sistemas de control de fuente, por lo que he agregado una respuesta un poco más profunda a su pregunta.

— Jiri Klouda

6

Es importante tener en cuenta que los términos "checkin" y "checkout" tienen diferentes significados según el tipo de sistema SCM.

Los sistemas centralizados como TFVC, Subversion y Clearcase usan pagos "exclusivos". Esto es como la metáfora del préstamo de libros de Pierre, donde solo un usuario puede tener un archivo desprotegido a la vez.

Los sistemas distribuidos como git tienen un comando de "pago", pero significa algo completamente diferente. git checkoutse usa para cambiar entre ramas cuando se trabaja con un repositorio local.

— Dave Swersky
fuente

Buen punto Dave sobre los sistemas distribuidos! En realidad, esa es también la razón por la que al principio (cuando supe por primera vez sobre GIT) estaba terriblemente confundido. Para no invalidar su respuesta (adaptando mi pregunta), refiné mi propia respuesta para aclararla un poco.

— Pierre.Vriens

Debo aclarar: git checkout se usa para retirar objetos del repositorio. Eso puede ser una rama o un solo archivo.

— Dave Swersky

4

Para sistemas centralizados, piense en ello como una biblioteca técnica. (podría ser un poco de imaginación cómo funciona esta biblioteca hipotética ...)

Si es autor de un documento, puede checkoutcopiar la biblioteca, hacer cambios, devolverlo check it back ina la biblioteca para que el mundo lo vea.

Esto puede convertirse en un problema si la biblioteca tiene copias digitales, y yo checkoutun documento, otra persona también checks outun documento, ambos hacemos cambios, habrá un conflicto (conflicto de fusión) que podría ser difícil de resolver. Cuando entonces la "solución" inicial para esto es una checkoutfuncionalidad exclusiva ...

Por supuesto, para los grandes proyectos se reducen las posibilidades de que un tema crítico conflicto de combinación (personas estarán trabajando en diferentes partes del sistema) por lo que checkout/ checkinno se necesita casi la misma cantidad. Y dado que los sistemas distribuidos por diseño requieren una buena funcionalidad de fusión, junto con muchos otros beneficios, ese concepto realmente no existe en git y otros DVCS

— Timina
fuente

Esa es otra forma de verlo. Aunque en mi experiencia no creo que sea una buena idea agregar también cosas como "conflictos" y "fusión" (si ni siquiera se sienten cómodos con el proceso de pago y registro).

— Pierre.Vriens

Justo, lo agregué porque es la razón principal por la que existe el checkout / checkin que se me ocurre. Y sentir que comprender un concepto es muy difícil si no sabes para qué es realmente útil ese concepto.

— Thymine

2

Con el repositorio SCM como tema principal, entonces '

el pago se realiza desde el repositorio local o remoto (en su directorio de trabajo local).
checkin vuelve a colocar los cambios en el repositorio local o remoto (desde su directorio de trabajo local).

— hlovdal
fuente

Merci por esta respuesta también . De hecho, esa es una forma de explicarlo, aunque todavía me pregunto si puedes pensar en algún tipo de "metáfora" (como en mi pregunta). Por ejemplo, explicarle a alguien a quien enseñarías, que ni siquiera tiene idea de lo que realmente es un repositorio local o remoto .

— Pierre.Vriens

Es cierto que si no tienen idea de qué es un repositorio, tratar de enseñar el registro y el registro no tendrá sentido. Ahora, para una metáfora del control de la fuente en general, puede compararlo con la contabilidad / contabilidad financiera. Es fundamentalmente realizar un seguimiento de los cambios en el valor de los activos. Usted registra cambios individuales individuales o grupos de cambios (por ejemplo, "Viaje de A a B" en lugar de boleto de taxi + ticker de autobús + boleto de tren + ...) aunque no grupos demasiado grandes (por ejemplo, "Todos los gastos el lunes"). Del mismo modo, un repositorio realiza un seguimiento de los cambios en el código fuente, grupos individuales o no demasiado grandes.

— hlovdal

1

Checkout es un bloqueo exclusivo para modificar una rama de objeto en un repositorio.

Checkin es un lanzamiento de bloqueo exclusivo.

Hay dos tipos de sistemas de control de fuente dependiendo de cuál es la unidad más pequeña de ramificación.

1) Por ramificación de repositorio (CVS, SVN, GIT, Perforce, ... etc.)

En los productos en los que ramifica todo el repositorio, el proceso de pago generalmente creará o habilitará modificaciones a la sucursal local (copia) de todo el repositorio. En esos productos, el registro a menudo no se utiliza y se convierte en parte de la operación de confirmación , que es a la vez el pago de la rama remota, la aplicación del parche local y el registro de la rama remota en una sola operación. No checkin su sucursal local, ya que se comprueba permanentemente. (Nota: en GIT no se compromete con la rama remota, empuja su confirmación local a ella. Estrictamente una diferencia sintáctica ) .

2) Por ramificación de objeto (ClearCase, AccuRev, Oracle ADE)

En productos donde ramifica objetos individuales, como directorios, archivos, etc. El concepto de pago y registro se aplica por objeto por rama. Bloqueará el objeto para modificarlo con el pago y liberarlo con el registro . En esos productos, a menudo trabaja en una rama privada donde las cerraduras no impiden que nadie trabaje y en el momento de la fusión de su rama local en una rama compartida, los objetos también se registran en la rama de fragmentos (principal, principal, rama característica, etc. ) los conflictos de fusión se resuelven y el objeto se registra en la rama compartida. Esto permite que varias personas se "comprometan" al mismo tiempo a una rama compartida siempre que no modifiquen los mismos objetos.

— Jiri Klouda
fuente

Hola Jiri, merci por tu respuesta. Para esos 2 tipos que mencionaste, estaría de acuerdo. Pero en las herramientas de SCM en el mundo de mainframe (de donde proviene mi experiencia) uno no tiene en cuenta el "bloqueo" ... ¿Se le ocurre una manera de agregar un tercer tipo a su respuesta?

— Pierre.Vriens

¿Me puede dar un ejemplo de un producto que no encaja en esas dos categorías? Puedo decirte cuál de los 2 encaja o agregar un tercero, si realmente hay uno. Checkout y checkin son operaciones en una sucursal que otorgan y liberan el derecho de modificarla. Entonces, la partición de lo que ramifica un producto (repositorio completo u objetos individuales) es natural para esta pregunta. No sé si hay algo en el medio, ¿cuál sería? La ramificación de subárboles como en Perforce y Subgit es esencialmente la primera categoría. Lock es solo un nombre diferente para un 'derecho exclusivo a'.

— Jiri Klouda

Por cierto, la metáfora de la biblioteca como se mencionó anteriormente es realmente buena. Cuando compras un libro, obtienes un derecho exclusivo sobre él. Lo llevas a casa y haces lo que quieras. Léalo o incluso escriba notas en los márgenes y nadie más puede modificar el libro, mientras lo tiene desprotegido. Como eliminar algunas de sus páginas o resaltar algunas líneas. Cuando revisa el libro, las personas pueden leerlo en la biblioteca, donde el ojo vigilante del bibliotecario no permite ninguna modificación (vandalismo) o lo echa un vistazo y se lo lleva a casa. Se serializa los cambios a ese libro.

— Jiri Klouda

Para continuar con la analogía, en una rama diferente de la biblioteca, el mismo libro podría estar allí con diferentes modificaciones o completamente inalterado o nada en absoluto. Alguien más puede verificarlo al mismo tiempo (es decir, el pago es por sucursal). Ahora el autor original trabaja en la segunda edición, una rama maestra, por así decirlo. Podía leer notas de varias ramas, fusionarlas, revisar la rama maestra y registrar una segunda edición. Cada rama de la biblioteca actualizará su copia comprando una segunda edición. Pueden descartar la primera o copiar notas útiles de los márgenes a la nueva edición.

— Jiri Klouda