Системи за контролу верзија

Version Control Systems - VCS

Проф. др Игор Дејановић (igord at uns ac rs)

Креирано 2024-09-30 Mon 13:38, притисни ESC за мапу, "м" за мени, Ctrl+Shift+F за претрагу

Sadržaj

1. Проблеми, подела и особине

1.1. Проблем са конкурентним изменама

  • Конкурентни развој подразумева да различити људи мењају исте ресурсе у исто време.
  • Како очувати све измене? Како их спојити на конзистентан начин?
  • Посебан проблем – чување историје промена.

1.2. Проблем са конкурентним изменама

KonkurentneIzmene-1.svg

Љубинка и Жика преузимају фајл А из дељеног репозиторијума.

KonkurentneIzmene-2.svg

Љубинка враћа измењену верзију фајла А.

KonkurentneIzmene-3.svg

Жика враћа измењену верзију преко Љубинкине верзије. Љубинкина измена је изгубљена.

1.3. Контрола верзија - Version Control

  • Контрола верзија (енг. Version Control) је општи назив за активност праћења промена и спајања конкурентних промена над артифактима од интереса за посматрану активност, уз очување историје.
  • У случају развоја софтвера артифакти који су предмет праћења могу бити било који дигитални садржаји који су део софтверског пројекта: модели, програмски код, документација, конфигурациони фајлови, мултимедијални садржаји и сл.
  • Представља део шире дисциплине под називом управљање конфигурацијом софтвера (енг. Software Configuration Management - SCM). SCM је инжењерска дисциплина која омогућава контролисано праћење и еволуцију софтверског производа.

1.4. Систем за контролу верзија

  • Систем за контролу верзија (Version Control System - VCS) управља променама над дигиталним артифактима (најчешће фајловима и фолдерима).
  • Даје увид у све промене које су учињене над артифактима који су предмет контроле верзија са свим релевантним метаподацима као што су:
    • Ко је начинио промену?
    • Када је промена учињена?
    • Шта је том приликом промењено и на који начин?
    • Над којом верзијом је промена учињена, односно које
    • промене су претходиле?
    • …
  • Омогућава враћање на верзију из прошлости и креирање алтернативних токова развоја/варијанти.

1.5. Модели управљања конкурентним променама

  • Песимистички (Lock-Modify-Unlock)
    • Конкурентне измене се избегавају закључавањем
    • Примена могућа само код централизованих система
    • Мане:
      • Смањена "пропусност" система – посебно изражено код пројеката са већим бројем учесника
      • Синдром "отишао на ручак"
  • Оптимистички (Copy-Modify-Merge)
    • Конкурентне промене се удружују накнадно (операција Merge).
    • Висока пропусност – сваки учесник може да ажурира произвољан артифакт.
    • Мане:
      • Конкурентне промене могу бити у конфликту што се разрешава приликом операције спајања.
      • Код произвољних бинарних фајлова где семантика садржаја није позната алату овај приступ не може да се користи.

1.6. Основни концепти

  • Промена (Change/Delta/Patch)
  • Скуп промена (ChangeSet)
  • Репозиторијум
  • Радна стабло/копија (Working Tree/Copy)

1.7. Постојеће архитектуре

  • Централизована или client-server архитектура.
    • Сва историја је у репозиторијуму централног сервера. Клијенти имају само текућу верзију.

Centralizovana-arhitektura.svg

  • Дистрибуирана или peer-to-peer архитектура.
    • Сваки клијент има пуну историју измена.

Distribuirana-arhitektura.svg

1.8. Централизовани системи за контролу верзија

  • Клијент-сервер архитектура.
  • Предности:
    • Могуће је успоставити строжију контролу.
    • Бољи увид у текуће стање пројекта.
  • Мане:
    • Све промене се виде на централном серверу што обесхрабује програмере на експериментисање.
    • Једна тачка отказа.
    • Код рада без интернета имамо појаву великих и нефокусираних промена (commit).
    • Лошија скалабилност у поређењу са дистрибуираним.

1.9. Дистрибуирани системи за контролу верзија

  • Системи који су имплементирани у складу са дистрибуираном архитектуром (peer-to-peer) називају се дистрибуираним системима за контролу верзија (Distributed Version Control Systems - DVCS).
  • Предности:
    • Рад без мреже. Креирање мањих, фокусираних промена (commit).
    • Једноставно креирање репозиторијума и експериментисање.
    • Једноставно гранање – сваки репозиторијум је грана развоја.
    • Једноставно креирање подтимова.
    • Једноставно базирање пројекта на већ постојећем (енг. forking).
    • Одлична скалабилност – пример: Линукс кернел.
    • Нов начин рада – друштвено кодирање (енг. social coding). Видети сајтове github.com, gitlab.org и bitbucket.org.

1.10. Основне VCS операције

  • Clone код DVCS, checkout код централизованих – Креирање радне копије.
  • Commit – Регистровање нове промене.
  • Update – Преузимање туђих промена
  • Pull/Push код DVCS – Пријем/слање промена из/у удаљених репозиторијума.

2. Централизовани системи

2.1. Најпознатији представници

2.2. Шта је Subversion?

  • Централизовани VCS отвореног кода настао као замена за времешни CVS.
  • Репозиторијум у којој се чува целокупна историја пројекта се налази на централном серверу.
  • Програмери приступају одређеним верзијама пројекта употребом SVN клијената.
  • Постоји више клијената у употреби: svn, TortoiseSVN, Subclipse, Subversive…
  • Сваки члан тима може изабрати са којим ће клијентом да ради.
  • Може користити и више клијената уколико жели.

2.3. Subversion архитектура

SVN-Arhitektura.png

  • B. Collins-Sussman, B. W. Fitzpatrick, and C. M. Pilato, Version Control with Subversion, For Subversion 1.7.

2.4. Модел Subversion репозиторијума

  • Репозиторијум је моделован као фајл систем са верзијама.
  • Почетна верзија је 0 и фајл систем је празан.
  • Операције над фајл системом су ACID (Atomicity-Consistency-Isolation-Durability) операције.
  • Свака успешна измена фајл система увећава верзију за 1.

SVNFileSystem.png

  • B. Collins-Sussman, B. W. Fitzpatrick, and C. M. Pilato, Version Control with Subversion, For Subversion 1.7.

3. Дистрибуирани системи за контролу верзија

3.1. Дистрибуирани системи - најпознатији представници

3.2. DVCS репозиторијум

DVCS-repo.svg

3.3. Комуникација између репозиторијума

DVCS-repos-push-pull.svg

3.4. Git

  • Развој започео Линус Торвалдс, у априлу 2005. године, после промене политике лиценцирања BitKeeper-а који је до тада коришћен за развој Линукс кернела.
  • Изузетно брз и скалабилан.
  • Писан највећим делом на језику Ц, али су делови писани у перлу, бешу итд.
  • Криптографска аутентификација историје промена.
  • Проблеми са превођењем на Windows платформу. Али то је сада мање-више решено.
  • Не прати фајлове већ садржај. Измене се експлицитно додају у међузону (индекс) пре регистровања промене.
  • Репозиторијум је потребно повремено “очистити”.

3.5. Mercurial

  • Брз, скалабилан и портабилан.
  • Писан највећим делом на језику Пајтон са критичним деловима написаним на Ц-у.
  • Једноставан за коришћење. Команде по узору на Subversion.
  • Један извшни фајл проширив путем екстензија.
  • Репозиторијум је адитивне природе. Није промењив и није потребно чишћење као код Git-а. Величина репозиторијума је увек минимална.
  • Проблематичан код великих фајлова.

3.6. Bazaar

  • За сада најспорији од “велике тројке”.
  • Писан највећим делом на језику Пајтон са деловима написаним на Ц-у.
  • Подржан од стране компаније Canonical.
  • Директна подршка за различите процесе.
  • Праћење назива директоријума и фајлова. Јака подршка за промене имена и премештање фајлова.

3.7. Fossil

  • Иницијална верзија у 2006 години. Написан на програмском језику Ц. Подаци се чувају у SQLite бази.
  • Иницијално коришћен на SQLite пројекту али данас се користи од стране више пројеката.
  • Поред система за контролу верзија обезбеђује дистрибуирану базу багова, форум, вики. Ово омогућава пуни дистрибуирани рад и у режиму без интернета.

3.8. Darcs

  • Имплементиран на програмском језику Haskell. Развој започет 2003. године.
  • Базиран на теорији закрпа (Theory of patches).
  • Репозиторијум је парцијално уређени скуп закрпа.
  • Операција примене независних закрпа је комутативна.
  • Закрпа А зависи од Б ако Б уводи садржај који А мења.
  • Већина других система је базирана на стању (Snapshot) док је базиран на променама, зато се многе операције (merge, rebase, cherry-pick) могу да се изведу употребом стандардних pull и push операција.
  • Још увек нерешени проблеми са експоненцијалном сложеношћу операције спајања у појединим случајевима, као и нерешена грешка код рекурзивних спајања.

3.9. Pijul

  • Релативно млад пројекат. Развој започет 2016. год. Имплементиран на програмском језику Rust.
  • Гради се на добрим идејама из Darcs-a али решава проблеме са перформансама и сложеношћу имплементације.
  • Оно што је грана у другим системима се моделује каналима (Channels). Свака закрпа може да припада каналима.
  • Конфликти су "грађани првог реда" и разрешење конфликта је нова промена/закрпа. Једном разрешени конфликт је разрешен трајно.
  • Могуће је радити над репозиторијумима који су парцијално клонирани и све промене су конзистентне са "главним/пуним" репозиторијумом. Ово обезбеђује и ефикасан рад у моделу моно-репозиторијума.