1. Що таке управління конфігурацією ПЗ?
2. Область застосування SCM
3. Мова SCM
4. архітектури
5. Централізовані vs. розосереджені репозиторії
6. Малюнок 1. При централізованій архітектурі все розробники працюють з центральним репозиторієм.
7. Малюнок 2. У нецентралізованої архітектурі розробники працюють, не сінхронізуясь один з одним, в своєму...
8. Модель "моментальних знімків" (snapshot model) проти Моделі "набору змін" (changeset model)
9. Малюнок 3. Кожна з моделей ( "знімків" і "наборів змін") має свої переваги.
10. приклади SCM
11. CVS
12. Лістинг 1. Приклади команд для CVS
13. Subversion
14. Лістинг 2. Приклади команд для Subversion
15. Arch
16. Лістинг 3. Приклади команд для GNU arch (tla)
17. Git
18. Лістинг 4. Приклади команд для Git
19. переваги
20. Погляд у майбутнє
21. Ресурси для скачування

Огляд архітектури, моделей і прикладів

Що таке управління конфігурацією ПЗ?

SCM - одне з тих найважливіших засобів, яке ви, можливо, не вивчали в школі. Як випливає з назви, управління ПО (або вихідним кодом) - це засіб і відповідний процес, який використовується для підтримки вихідного коду і його зміни з плином часу. SCM надає наступні можливості:

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

Область застосування SCM

Контроль вихідного коду (source control) зазвичай має на увазі управління вихідним кодом і пов'язаними з ним файлами, тоді як управління вихідним кодом (source management) може застосовуватися до будь-яких типів ресурсів. Веб-сайт, що складається з HTML файлів і файлів зображення, звичайних текстових документів, і файлів будь-якого іншого типу, є кандидатом на управління версіями за допомогою SCM систем.

Таким чином, SCM дозволяє управляти набором файлів в репозиторії і робити перевірки цих файлів. Якщо зміни в файлах виробляються різними розробниками, SCM визначає конфлікти, викликані вашими змінами та або автоматично їх синхронізує, або сповіщає вас про конфлікт. Така функціональність дуже важлива, оскільки з її допомогою кілька розробників можуть змінювати один і той же набір файлів. SCM також надає можливість враховувати, хто і які зробив зміни. Нарешті, SCM дозволяє логічно групувати файли, наприклад, поміщати в один набір виконавчі файли або образи.

Мова SCM

Перш ніж глибоко пірнути в деталі і типи архітектур для SCM, вам потрібно вивчити словник. Перший термін - репозиторій (repository). Репозиторій - це центральне місце, де зберігаються файли (іноді його називають деревом [tree]). Витяг файлів з репозиторію в робочу директорію вашої локальної системи називається вивантаження (check-out). Якщо ви робите зміни в файлах локально, для їх синхронізації зі змінами файлів в репозиторії, вам потрібно зафіксувати (commit) зміни. Якщо ваш змінений файл до цього був змінений кимось ще, відбудеться об'єднання змін, тобто два набори змін будуть зведені разом. Якщо об'єднання неможливе через конфліктуючих змін в файлі, виникне конфлікт (conflict). У такій ситуації, commit відхиляється і розробнику доводиться погоджувати зміни вручну. Коли зміни зафіксовані, створюється нова версія (revision) файлу.

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

Для того, щоб позначити початок відліку змін в дереві, можна поставити мітку (tag) на наборі файлів, згрупувавши таким чином кілька файлів в придатний для використання блок (іноді використовується в якості кінцевої версії файлів для якоїсь окремої збірки).

архітектури

SCM системи можуть істотно різнитися, але є два головних архітектурних відмінності, які варто вивчити:

• Централізовані vs. розосереджені репозиторії
• Метод "змін" vs. Метод "моментального знімка"

Централізовані vs. розосереджені репозиторії

Одне з найбільш важливих архітектурних відмінностей в сучасних SCM, яке ви можете побачити і відчути в своїй роботі - це ідея централізованих репозиторіїв проти розосереджених (або нецентралізованих). Найбільш поширеною архітектурою в наші дні є архітектура з централізованим репозиторієм. Дана "зоряна" (star) архітектура зображується як центральний репозиторій ресурсів і безліч розробників працюють з ним (див. Малюнок 1). Розробник вивантажує код з центрального сховища на локальну машину (check out), і після внесення змін, фіксує їх і завантажує назад в центральний репозиторій (commit), таким чином, і інші розробники мають доступ до його змін.

Малюнок 1. При централізованій архітектурі все розробники працюють з центральним репозиторієм.

У центральному репозиторії також можна створювати гілки, що дозволяє розробникам спільно працювати над внесенням змін до початкового коду, що зберігається в репозиторії, причому за головною гілки (mainline).

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

Малюнок 2. У нецентралізованої архітектурі розробники працюють, не сінхронізуясь один з одним, в своєму власному репозиторії.

Нецентралізована архітектура цікава тим, що незалежні розробники можуть працювати асинхронно в тимчасової мережі (peer to peer). Коли робота закінчена (і досить стабільна), вони можуть зробити набір своїх змін (або виправлень) доступним всім іншим. Така модель в наші дні широко використовується в розробці систем з відкритим кодом, включаючи ядро ​​Linux® kernel.

Модель "моментальних знімків" (snapshot model) проти Моделі "набору змін" (changeset model)

Інше цікаве архітектурне відміну старих SCM від більш сучасних - спосіб зберігання змін. Теоретично системи однакові і дають один і той же результат, але розрізняються тим, як зберігаються версії файлів (revision).

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

Малюнок 3. Кожна з моделей ( "знімків" і "наборів змін") має свої переваги.

Як ви бачите з малюнка 3, моделі відрізняються, але в кінцевому підсумку ми отримуємо однаковий результат. У моделі "моментальних знімків", ви можете отримати версією швидко, але вам буде потрібно більше місця, щоб зберігати їх. Модель "набір змін" вимагатиме менше місця, але займе більше часу, для отримання певної версії, тому що помилка повинна бути врахована в основну версію. Як ви потім побачите, ви можете робити оптимізацію, щоб мінімізувати кількість помилок, які враховуються в моделі.

приклади SCM

Давайте поглянемо на кілька SCM систем, що розрізняються архітектурою: централізована проти розміщеної. Як ви скоро дізнаєтеся, деякі SCM можуть підтримувати обидві моделі.

CVS

Concurrent Versions System (CVS) - одна з найбільш поширених сьогодні SCM. Вона має централізовану архітектуру з моделлю "набору змін", в якій розробники працюють з центральним репозиторієм при спільній розробці програмного забезпечення. CVS використовується повсюдно і вона доступна як стандартна частина будь-якого дистрибутива Linux. Завдяки своєму простому і зручному (для багатьох з нас) синтаксису, вона є популярним вибором як при одиночній, так і командної розробки.

Лістинг 1 демонструє набір простих CVS команд з коротким описом кожної. Для більш докладної інформації, зверніться до секції ресурси .

Лістинг 1. Приклади команд для CVS

# Створити новий репозиторій cvs -d / home / user / new_repository init # Під'єднатися до кореневого сховища export CVSROOT =: pserver: [email protected]: / cvs_root # вивантажити блок для модуля з кореневого сховища cvs checkout project # Оновити локальний блок з кореневого сховища cvs update # Внести зміни з локального блоку в Конєва репозиторій cvs commit # Додати нові файли в локальний блок cvs add <file / subdirectory> # Показати зміни, зроблені в локальному блоці cvs diff

Для любителів інтерфейсу з використанням координатного покажчика ( "мишачий" інтерфейс) в CVS є велика кількість графічних інтерфейсів з відкритим кодом, які ви можете використовувати, наприклад, WinCVS і TortoiseCVS (яка інтегрується з Microsoft Windows Explorer, якщо вам це зручно).

Незважаючи на повсюдне використання, CVS має свої недоліки. CVS не дозволяє перейменовувати файли, також вона має недоліки при роботі з певними файлами, наприклад, з символьними посиланнями. Зміни, що відслідковують самим файлом, можуть іноді набридати. Синхронізація може бути іноді проблематична (CVS всередині використовує diff3 для цієї мети).

Однак, CVS корисний, якщо дійсно це необхідно зробити, і він придатний для всіх головних платформ. Якщо вам подобається CVS, в цілому, то Subversion може бути для вас як раз тим, що ви шукаєте.

Subversion

Subversion (SVN) була розроблена як пряма заміна CVS, але без властивих CVS заздалегідь визначених випусків. Як і CVS, Subversion - централізоване рішення і використання моделі "моментального знімка". Її команди, схожі на ті ж команди CVS, але з новими доповненнями, добре справляються з такими речами, як видалення файлів, перенаіменованіе файлів або повернення до оригінального файлу.

Subversion також дозволяє віддалений доступ за допомогою великої кількості протоколів, таких як протокол HTTP, протокол безпеки HTTP, або протокол, виконаний на замовлення SVN, який також підтримує тунелювання через Оболонку Безпеки [SSH].

Лістинг 2 показує деякі з команд, які підтримуються в Subversion. Ми також включили деякі з розширень, які не придатні для CVS. подивіться розділ ресурси для більш детальної інформації про Subversion. Як ви бачите, набір команд Subversion дійсно схожий на набір команд CVS, забезпечуючи хорошу альтернативу для CVS-користувачів.

Лістинг 2. Приклади команд для Subversion

# Створити новий репозиторій svnadmin create / home / user / new_repository # вивантажити блок з кореневого сховища svn checkout file: /// server / svn / existing_repository new_repository # Оновити локальний блок з кореневого сховища. svn update # Внести зміни з локального блоку в кореневій репозиторій. svn commit # Додати нові файли в локальний блок svn add <file / subdirectory> # Показати зміни, зроблені в локальному блоці svn diff # Перейменувати файл в локальному блоці svn rename <old_file> <new_file> # Видалити файли svn delete <file / subdirectory>

Наслідуючи традиції CVS, Subversion використовує в роботі графічний зовнішній інтерфейс, такий як ViewCVS and TortoiseSVN. Існують також засоби конвертувати репозиторій CVS в Subversion (такі як cvs2svn.py), але вони, як повідомляють, управляються не з усім набором відгалужень і супроводів даних тегами в випадках складних репозиторіїв. З огляду на все Open Source проекти, згодом ситуація покращиться. Subversion також використовує в роботі TortoiseMerge як відмінності між засобами відображення і виправлення.

У Subversion фіксування число випусків, випробуваних CVS користувачами, такі як організація розробки нових поколінь певних файлів, дрібних дій і отладок. Якщо вам подобається CVS і вам подобається підхід центрального сховища, то Subversion - це SCM для вас.

Тепер давайте відштовхнемось від централізованого підходу і розглянемо приклад, коли деякі думають, що реальне майбутнє SCM - це об'єднання децентралізованих репозиторіїв.

Arch

Arch - це докладний детальний опис для децентралізованої SCM, яке пропонує безліч різних моделей. Вони включають в себе ArX, Bazaar, GNU Arch, і Larch. Arch не тільки оперує як децентралізована SCM (як показано на малюнку 2), але також використовує модель "набору змін" (рисунок 3). Arch SCM - популярний метод для Разрабока Open Source, оскільки розробники зможуть створювати в окремих репозиторіях з повним контролем вихідного коду. Це відбувається тому що розосереджені репозиторії - діючі репозиторії, доповнені контролем перевірок (revision). Ви можете створювати patch з змін в локальній репозиторії, використовуваному вищим розробником. Це велика перевага децентралізованої моделі.

Як і Subversion, Arch коригує число випусків в CVS. Вони включають в себе зміни метаданих, такі як переосмислення дозволів файлу, обробка видалення і перейменування файлів, і невеликі порівняння (злиття порівнянь замість окремо діючих порівнянь).

Лістинг 3 показує деякі з команд, які ви знайдете в Arch SCM. Ми продемонстрували тут GNU arch, так як він розроблений архітектором Arch, Томом Лордом. GNU arch забезпечує базу, яку ви чекаєте від SCM, включаючи новітні опції, наявні в Subversion.

Лістинг 3. Приклади команд для GNU arch (tla)

# Реєстрація публічного архіву tla register-archive http://www.mtjones.com/arch # Вивантаження локального сховища з вищого. tla get [email protected]/project--stable myproject # Оновлення з локального сховища. tla update # Внесення змін до локальний репозиторій. tla commit # Додавання нових файлів в локальний репозиторій. tla add <file> # Показати зміни, зроблені в локальному репозиторії. tla what-changed # Перейменувати файл в локальному репозиторії. tla mv <old_file> <new_file> # Видалити фaйли (також видалити зі сховищ) tla rm <file>

Arch також дозволяє синхронізувати зміни від вищестоящих репозиторіїв. Щоб мінімізувати число виправлень, які потрібно буде застосувати до основної перевірці (за допомогою модуля "набору змін"), команда "cacherev" створить новий "моментальний знімок" основний перевірки в репозиторії.

Перевага Arch полягає в тому, що незважаючи на те, що він разрабивался як децентралізований процес, він може також бути використаний в прикладі централізованого сховища.

Найбільший протест від нових користувачів tla викликала деяка заплутаність Arch. Інші дії Arch, такі як baz, як кажуть експерти, легше. Ви можете розглядати їх, якщо tla не задовольнить ваші вимоги.

Тепер розглянемо остаточну децентралізовану SCM, написану розробником ядра Linux власноруч, Лінусом Торвальдом.

Git

Git SCM був розроблений Лінусом Торвальдом як пряма заміна для Bitkeeper SCM (див. Секцію ресурси Це дуже просто, але це коштує роботи децентралізованої SCM, заснованої на методі "набору змін" і використовується як SCM для ядра Linux. Він використовує модель угруповання файлів більше, ніж відстеження окремими файлами. Зміни стиснуті і роздроблені за допомогою SHA1, підтверджуючи їх цілісність. (Див. Лістинг 4)

Лістинг 4. Приклади команд для Git

# Отримати Git репозиторій (вперше) git clone \ git: //git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git # Оновити Git репозиторій з певного вищого Git сховища git pull # вивантажити з Git сховища в локально працює репозиторій. git checkout # Додати зміни в локальний Git репозиторій git commit # Внести зміни до вищестоящого (зажадає SSH доступ до вищестоящого git push # Додати нові файли в локальний репозіторійires (commit) git add <file> # Показати зміни, зроблені в локально працює діркторіі git diff # Видалити файли git rm <file>

Git SCM - самодостатній в своєму власному репозиторії Git, що позначає що ви повинні завантажити Git, щоб інсталювати його на своїй машині. Набір команд для Git, схожий з тим, що ви бачили до цього, - щодо основний набір команд.

Ви можете запитати, чому не розглядаємо жодну з існуючих SCM, крім тих, які описані тут? Це хороше запитання. Git цікавий і зберігає велику користувача базу розробників ядра Linux, тому це могло бути наступною великою SCM. Лінус описує Git як дуже швидкого менеджера вмісту директорії, який хоч і не робить багато, але робить це ефективно.

переваги

Який тип SCM ви б не використовували, є універсальний набір переваг, які ви отримаєте. З SCM ви можете відстежувати зміни файлів і знати, як розвивалося ваше ПО. Коли відбуваються неправильні зміни, ви можете знайти їх і повернутися до первісного джерела. Ви можете групувати набори файлів разом і маркувати їх, щоб зробити версію, яка може бути вивантажено в будь-який час, повторно ладу певні версії коду (вимога SCM).

Чи використовуєте ви централізований або розосереджений репозиторій, модель "знімка" або "змін", переваги однакові. Так як розробка сучасного ПО не обходиться без SCM, використовуйте SCM завчасно і використовуйте його часто!

Погляд у майбутнє

Ця стаття - поверхневий погляд на SCM в його використанні на сьогоднішній момент. Існує багато інших Open Source SCM, включаючи Aegis, Bazaar-NG, DARCS, і Monotone, наприклад. Як редактори і мови, SCM можуть бути неясними, оскільки вони рідко використовуються в ізоляції, і, таким чином, зазвичай вибираються командами більше, ніж в індивідуальному порядку (якщо у вас не особливо владний начальник, який любить приймати рішення за вас). Тому, грайте з можливостями і розвивайтеся в різних напрямках. SCM - необхідний інструмент в розробці ПЗ і значна частина вашого технічної панелі інструментів.

Ресурси для скачування

Схожі тими

• оригінал статті Version Control for Linux .
• Розгляньте велика кількість систем SCM для Linux на LinuxMafia.
• прочитайте цікаву статтю Девіда Віллера про Open Source, SCM, відкритті CVS, Subversion, Arch, і Monotone.
• CVS - одні з найстаріших і розповсюджених систем SCM.
• Subversion чудова альтернатива CVS.
• GNU arch одна з реалізацій Arch SCM специфікації, Том Лорд.
• Нік Моффіт дає цікавий погляд на Arch в " Контроль Перевірок з Arch: Введення в Arch "(Linux Журнал, листопада 2004).
• Том Коупланд показує, як StatCVS можуть бути використані, щоб створити charts з CVS даних в статті " За допомогою StatCVS заглянемо в активність репозиторіїв CVS "(DeveloperWorks, лютий 2005).
• Дізнайтеся більше про Git в статті " Лінус Торвальд розповідає про побудову Git "(EWeek, квітень 2005).
• Розгляньте Git в цьому номері Керівництво для розробників ядра (kernel hackers) .
• подівіться Aegis - SCM, заснована на транзакції.
• Ця стаття порівняння VCS дає цікаве порівняння характеристик великої кількості систем SCM
• Вивчіть програмування Linux з коштів APIs і більше використовуючи Програмування в GNU / Linux (Чарльз Рівер, січень 2005).
• Для більш детального огляду CVS, прочитайте " CVS для розробників (DeveloperWorks, березень 2001).
• Для огляду IBM продуктів, з серії SCM, погляньте на сторінку Раціональні зміни і управління конфігурацією .
• на порталі "developerWorks" для Linux , Знайдіть більше ресурсів для розробників Linux.
• с помощью IBM триальной версії ПЗ , Доступним для скачування з робіт розробників, зробіть ваш наступний проект в Linux.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів