Яка різниця між реєстрацією та замовленням?

Під час викладання класів 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 в якості основного об'єкта , потім »

• виписка отримує зміни ПОЗА з локального або віддаленого сховища (в локальному робочому каталозі).
• чекін повертає зміни в локальний або віддалений сховище (з місцевого робочого каталогу).

• Оформити замовлення - це ексклюзивний замок для зміни гілки об'єкта у сховищі.
• Checkin - це випуск ексклюзивного замка.

Існує два види систем управління джерелами залежно від того, яка найменша одиниця розгалуження.

1) За розгалуження сховища (CVS, SVN, GIT, Perforce, ... тощо)

У продуктах, де ви здійснюєте відділення всього сховища, каси зазвичай створюють або вмикають зміни в локальній філії (копії) всього сховища. У цих продуктах checkin часто не використовується і стає частиною операції фіксації , яка є одразу замовленням віддаленого відділення, застосовуючи локальний патч та реєстрацію віддаленого відділення за одну операцію. Ви не приїзду в місцеве відділення , як це постійно перевірили. (Примітка. У GIT ви не зобов’язуєтесь віддалену гілку, ви підштовхуєте її до місцевої комісії. Суворо синтаксична різниця. )

2) За розгалуженням об'єктів (ClearCase, AccuRev, Oracle ADE)

У продуктах, де ви розгалужуєте окремі об'єкти, як-от каталоги, файли тощо. Поняття оформлення замовлення та реєстрації застосовується для кожного об'єкта на галузь. Ви заблокуєте об'єкт, щоб змінити його під замовленням та звільнити його за допомогою реєстрації . У цих продуктах ви часто працюєте на приватній гілці, де блокування не перешкоджає нікому працювати, а під час об'єднання вашої місцевої гілки в спільну гілку об'єкти також перевіряються на осколковій гілці (головна, головна, гілка функції тощо) ) Вирішуються конфлікти злиття та перевіряється об'єкт у спільній гілці. Це дозволяє декільком людям одночасно "вчиняти" спільну гілку до тих пір, поки вони не змінюють однакові об'єкти.