При преподавании классов SCM студентам, которые не знакомы с управлением конфигурацией программного обеспечения, возникает вопрос, который выглядит как " What's the difference between checkin and checkout?".
И вариация этого заключается в том, что такие студенты запутываются в этих концепциях SCM (они понимают их, как наоборот).
Так какую метафору вы можете использовать, чтобы объяснить эту важную концепцию SCM такой аудитории?
terminology
scm
Pierre.Vriens
источник
источник
Ответы:
Чтобы что-то кому-то объяснить, попытайтесь сравнить это с тем, с чем они (надеюсь) уже знакомы.
Поэтому я просто отвечаю на такой вопрос:
Примечание : это относится к централизованным системам (например, используемым в средах мэйнфреймов ...). В таких системах, как 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 в качестве основной темы
источник
Существует два вида систем управления исходным кодом в зависимости от того, какая наименьшая единица ветвления.
1) Разветвление репозитория (CVS, SVN, GIT, Perforce и т. Д.)
В продуктах, в которых вы разветвляете весь репозиторий, checkout обычно либо создает, либо включает изменения в локальной ветви (копии) всего репозитория. В этих продуктах регистрация часто не используется и становится частью операции фиксации , которая является одновременно проверкой удаленной ветви, применением локального исправления и регистрацией удаленной ветви в одной операции. Вы не регистрируетесь в своем местном отделении, поскольку оно постоянно проверено. (Примечание: в GIT вы не фиксируете удаленную ветвь, вы помещаете в нее локальную фиксацию. Строго синтаксическая разница. )
2) Для каждого ветвления объекта (ClearCase, AccuRev, Oracle ADE)
В продуктах, где вы разветвляете отдельные объекты, такие как каталоги, файлы и т. Д. Концепция извлечения и регистрации применяется для каждого объекта в ветви. Вы заблокируете объект, чтобы изменить его с помощью checkout и освободить его с помощью checkin . В этих продуктах вы часто работаете в частной ветви, где блокировки никому не мешают работать, и во время слияния вашей локальной ветви в общую ветку объекты также извлекаются в ветке сегмента (основной, основной, ветвь функций и т. Д.). ) конфликты слияния разрешаются и объект проверяется в общей ветке. Это позволяет нескольким людям одновременно «фиксировать» в общей ветке, если они не изменяют одни и те же объекты.
источник