В чем разница между регистрацией и оформлением заказа?

При преподавании классов SCM студентам, которые не знакомы с управлением конфигурацией программного обеспечения, возникает вопрос, который выглядит как " What's the difference between checkin and checkout?".

И вариация этого заключается в том, что такие студенты запутываются в этих концепциях SCM (они понимают их, как наоборот).

Так какую метафору вы можете использовать, чтобы объяснить эту важную концепцию SCM такой аудитории?

Чтобы что-то кому-то объяснить, попытайтесь сравнить это с тем, с чем они (надеюсь) уже знакомы.

Поэтому я просто отвечаю на такой вопрос:

Думайте об этом как о прибытии в место для проживания (отель, курорт и т. Д.):

• самое первое, что вы делаете (когда вы приедете), это checkin.
• самое последнее, что вы делаете (когда уходите) - это checkout.

Аналогичная концепция SCM применяется, когда вы хотите применить изменения к программным компонентам ... за исключением того, что она применяется наоборот :

• самое первое, что вы делаете (когда начинаете), это checkout(или думаете об этом, как о заимствовании).
• самое последнее, что вы делаете (когда заканчиваете), это checkin(или думаете об этом, как о возвращении).

Примечание : это относится к централизованным системам (например, используемым в средах мэйнфреймов ...). В таких системах, как git,checkout понятие « » имеет совершенно другое значение (что, по мнению IMO, в этих системах вряд ли вызывает путаницу в отношении обеих концепций).

Важно отметить, что термины «регистрация» и «оформление заказа» имеют разные значения в зависимости от типа системы SCM.

Централизованные системы, такие как TFVC, Subversion и Clearcase, используют «эксклюзивные» проверки. Это похоже на метафору заимствования книги Пьера, где только один пользователь может получить файл за один раз.

Распределенные системы, такие как git, имеют команду checkout, но это означает что-то совершенно другое. git checkoutиспользуется для переключения между ветками при работе с локальным репозиторием.

Для централизованных систем думайте об этом как о технической библиотеке. (может быть, воображение, как функционирует эта гипотетическая библиотека ...)

Если вы являетесь автором документа, вы можете checkoutскопировать библиотеку, внести изменения, вернуть ее check it back inв библиотеку, чтобы ее увидел весь мир.

Это может стать проблемой, если в библиотеке есть цифровые копии, а я checkoutдокумент, кто-то еще и checks outдокумент, мы оба вносим изменения, возникает конфликт (конфликт слияния), который может быть трудно разрешить. Когда тогда первоначальное «исправление» для этого является эксклюзивным checkoutфункционалом ...

Конечно, для крупных проектов вероятность критической проблемы слияния уменьшается (люди будут работать в разных частях системы), поэтому checkout/ checkinне нужна почти так же. А поскольку распределенные системы по своему дизайну в некоторой степени требуют хорошей функциональности слияния, наряду со многими другими преимуществами, эта концепция на самом деле не существует в git и других DVCS.

С хранилищем SCM в качестве основной темы

• checkout - это получение изменений из локального или удаленного репозитория (в ваш локальный рабочий каталог).
• checkin помещает изменения обратно в локальный или удаленный репозиторий (из вашего локального рабочего каталога).

• Checkout - это эксклюзивная блокировка для изменения ветви объекта в хранилище.
• Checkin - это выпуск эксклюзивной блокировки.

Существует два вида систем управления исходным кодом в зависимости от того, какая наименьшая единица ветвления.

1) Разветвление репозитория (CVS, SVN, GIT, Perforce и т. Д.)

В продуктах, в которых вы разветвляете весь репозиторий, checkout обычно либо создает, либо включает изменения в локальной ветви (копии) всего репозитория. В этих продуктах регистрация часто не используется и становится частью операции фиксации , которая является одновременно проверкой удаленной ветви, применением локального исправления и регистрацией удаленной ветви в одной операции. Вы не регистрируетесь в своем местном отделении, поскольку оно постоянно проверено. (Примечание: в GIT вы не фиксируете удаленную ветвь, вы помещаете в нее локальную фиксацию. Строго синтаксическая разница. )

2) Для каждого ветвления объекта (ClearCase, AccuRev, Oracle ADE)

В продуктах, где вы разветвляете отдельные объекты, такие как каталоги, файлы и т. Д. Концепция извлечения и регистрации применяется для каждого объекта в ветви. Вы заблокируете объект, чтобы изменить его с помощью checkout и освободить его с помощью checkin . В этих продуктах вы часто работаете в частной ветви, где блокировки никому не мешают работать, и во время слияния вашей локальной ветви в общую ветку объекты также извлекаются в ветке сегмента (основной, основной, ветвь функций и т. Д.). ) конфликты слияния разрешаются и объект проверяется в общей ветке. Это позволяет нескольким людям одновременно «фиксировать» в общей ветке, если они не изменяют одни и те же объекты.