Сістэма кіравання версіямі

З пляцоўкі Вікіпедыя.
Перайсці да: рух, знайсці

Сістэма кіравання версіямі (ад англ.: Version Control System, VCS ці Revision Control System) — праграмнае забеспячэнне для палягчэння работы са зменлівай інфармацыяй. Сістэма кіравання версіямі дазваляе захоўваць некалькі версій аднаго і таго ж дакумента, пры неабходнасці вяртацца да больш ранніх версій, вызначаць, хто і калі зрабіў тую ці іншую змену, і шмат іншага.

Такія сістэмы найбольш шырока ўжываюцца пры распрацоўцы праграмнага забяспечання для захоўвання крынічных кодаў праграмы, якая распрацоўваецца. Аднак яны могуць з поспехам выкарыстоўвацца і ў іншых праектах, дзе вядзецца работа з вялікай колькасцю няспынна зменлівых электронных дакументаў. У прыватнасці, сістэмы кіравання версіямі выкарыстоўваюцца ў САПР, звычайна ў складзе сістэм кіравання данымі аб вырабах (PDM). Кіраванне версіямі ўжываецца ў інструментах канфігурацыйнага кіравання (Software Configuration Management Tools).

Праграмнае забеспячэнне Вікіпедыі захоўвае гісторыю зменаў для ўсіх яе артыкулаў, ужываючы метады, аналагічныя тым, якімі карыстаюцца ў сістэмах кіравання версіямі.

Агульныя сведкі[правіць | правіць зыходнік]

Сітуацыя, у якой электронны дакумент за час свайго існавання зведвае шэраг зменаў, з'яўляецца даволі тыповай. Пры гэтым часта бывае важна мець не толькі апошнюю версію, але і некалькі папярэдніх. У найпростым выпадку можна проста захоўваць некалькі варыянтаў дакумента, нумеруючы іх адпаведным чынам. Такі спосаб неэфэктыўны (даводзіцца захоўваць некалькі амаль ідэнтычных копій), патрабуе больш увагі і дысцыпліны і часта вядзе да памылак, таму былі распрацаваны сродкі для аўтаматызацыі гэтай работы.

Традыцыйныя сістэмы кіравання версіямі ўжываюць цэнтралізаваную мадэль, калі маецца адзінае сховішча дакументаў, якое кіруецца спецыяльным серверам, які і выконвае большую частку функцый кіравання версіямі. Карыстальнік, які працуе з дакументамі, павінен спачатку атрымаць патрэбную яму версію дакумента са сховішча; звычайна ствараецца лакальная копія дакумента, т. з. «рабочая копія». Можа быць атрымана апошняя версія ці любая з папярэдніх, якая можа быць абрана па нумару версіі ці даце стварэння, альбо па іншым прызнакам. Пасля таго, як у дакумент унесены патрэбныя змены, новая версія змяшчаецца ў сховішча. У адрозненні ад простага захоўвання файла, папярэдняя версія не знішчаецца, а таксама застаецца ў сховішчы і можа быць атрыма адтуль у любы час. Сервер можа ўжываць т. з. дэльта-кампрэсію — гэта такі спосаб захоўвання дакументаў, пры якім захоўваюцца толькі змены паміж паслядоўнымі версіямі, што дазваляе паменшыць аб'ём даных у сховішчы. Улічваючы, што звычайна найбольш запатрабаванай з'яўляецца апошняя версія файла, сістэма можа пры захоўванні новай версіі захоўваць яе цалкам, замяняючы ў сховішчы апошнюю раней захаваную версію на розніцу паміж гэтай і свежай версіяй. Некаторыя сістэмы (напрыклад, ClearCase) падтрымліваюць захоўванне версій абодвух відаў: большасць версій захоўваецца ў выглядзе дэльта, але перыядычна (па спецыяльнай камандзе адміністратара) выконваецца захоўванне версій усіх файлаў у поўным выглядзе; такі падыход забяспечвае максімальна поўнае аднаўленне гісторыі ў выпадку пашкоджання рэпазітара.

Часам стварэнне новай версіі выконваецца незаўважна для карыстальніка (празрыста), альбо прыкладной праграмай, якая мае ўбудаваную падтрымку такой функцыі, альбо за кошт ужывання спецыяльнай файлавай сістэмы. У гэтым выпадку карыстальнік проста працуе з файлам, як звычайна, і падчас захоўвання файла аўтаматычна ствараецца новая версія.

Звычайнай з'яўляецца сітуацыя, калі над адным праектам працуюць адначасова некалькі чалавек. Калі два чалавека змяняюць адзін і той жа файл, то адзін з іх можа выпадкова адмяніць змены, зробленыя другім. Сістэмы кіравання версіямі адсочваюць такія канфлікты і прапаноўваюць сродкі іх вырашэння. Большасць сістэм можа аўтаматычна аб'ядноўваць (зліваць) змены, зробленыя рознымі распрацоўшчыкамі. Аднак такое аўтаматычная аб'яднанне зменаў звычайна магчыма толькі для тэкставых файлаў і пры ўмове, што змяняліся розныя часткі (якія не перасякаюцца) гэтага файла. Такое абмежаванне звязана з тым, што большасць сістэм кіравання версіямі арыентаваны на падтрымку працэса распрацоўкі праграмнага забяспечання, а крынічныя коды праграм захоўваюцца ў тэкставых файлах. Калі аўтаматычнае аб'яднанне выканаць не ўдалося, сістэма можа прапанаваць вырашыць праблему ўручную.

Часта выканаць зліццё немагчыма ні ў аўтаматычным, ні ў ручным рэжыме, напрыклад, калі фармат файла невядомы ці занадта складаны. Некаторыя сістэмы кіравання версіямі даюць магчымасць заблакаваць файл у сховішчы. Блакаванне не дазваляе іншым карыстальнікам атрымаць рабочую копію ці забараняе змены рабочай копіі файла (напрыклад, сродкамі файлавай сістэмы) і забяспечвае такім чынам выключны доступ толькі таму карыстальніку, які працуе з дакументам.

Многія сістэмы кіравання версіямі прадастаўляюць шэраг іншых магчымасцяў:

  • Дазваляюць ствараць розныя варыянты аднаго дакумента, г. з. галіны, з агульнай гісторыяй зменаў да пункту разгалінавання і з рознымі — посля яе.
  • Даюць магчымасць даведацца, хто і калі дадаў ці змяніў пэўны набор радкоў у файле.
  • Вядуць журнал зменаў, у якім карыстальнікі могуць запісваць тлумачэнні аб тым, што і чаму яны змянілі ў дадзенай версіі.
  • Кантралююць правы доступу карыстальнікаў, дазваляючы ці забараняючы чытанне ці змены даных, у залежнасці ад таго, хто запытвае гэтае дзеянне.

Тыповы парадак работы з сістэмай[правіць | правіць зыходнік]

Кожная сістэма кіравання версіямі мае свае спецыфічныя асаблівасці ў наборы каманд, парадку работы карыстальнікаў і адміністраванні. Між тым, агульны парадак работы для большасці VCS цалкам стэрэатыпны. Будзем меркаваць, што праект, якім бы ён ні быў, ужо існуе і на серверы размешчаны яго рэпазітар, да якога распрацоўшчык атрымоўвае доступ.

Пачатак работы з праектам[правіць | правіць зыходнік]

Першым дзеяннем, якое павінен выканаць распрацоўшчык, з'яўляецца атрыманне рабочай копіі праекта ці той яго часткі, з якой належыць работаць. Гэтае дзеянне выконваецца з дапамогай стандартнай каманды атрымання версіі (checkout ці clone) альбо спецыяльнай команды, якая фактычна выконвае тое ж самае дзеянне. Распрацоўшчык задае версію, якая павінна быць скапіявана, па змоўчванню звычайна капіюецца апошняя (ці абраная адміністратарам у якасці асноўнай) версія.

Па камандзе атрымання ўсталёўваецца злучэнне з серверам і праект (ці яго частка — адзін з каталогаў з падкаталогамі) у выглядзе дрэва каталогаў і файлаў капіюецца на камп'ютар распрацоўшчыка. Звычайнай практыкай з'яўляецца дубляванне рабочай копіі: апроч асноўнага каталога з праектам на лакальны дыск (альбо ў асобны, спецыяльна абраны каталог, альбо ў сістэмныя падкаталогі асноўнага дрэва праекта) дадаткова запісваецца яшчэ адна яго копія. Працуючы з праектам, распрацоўшчык змяняе толькі файлы асноўнай рабочай копіі. Другая лакальная копія захоўваецца ў якасці эталона, дазваляючы ў любы момант без звяртання да сервера вызначыць, якія змены ўнесены ў пэўны файл ці праект ў цэлым і ад якой версіі была «адгалінавана» рабочая копія; як правіла, любая спроба ручной змены гэтай копіі вядзе да памылак у рабоце праграмнага забяспечання VCS.

Штодзённы цыкл работы[правіць | правіць зыходнік]

Пры некаторых вырыяцыях, вызначаных асаблівасцямі сістэмы і дэталямі прынятага бізнэс-працэса, звычайны цыкл работы распрацоўшчыка напрацягу для выглядае наступным чынам.

Аднаўленне рабочай копіі 
Па меры ўнясення зменаў у праект рабочая копія на камп'ютары распрацоўшчыка старэе, разыходжанне яе з асноўнай версіяй праекта павялічваецца. Гэта павышае рызыку ўзнікнення канфліктных зменаў (гл. ніжэй). Таму зручна падтрымліваць рабочую копію ў стане, максімальна блізкім да бягучай асноўнай версіі, дзеля чаго распрацоўшчык воконвае аперацыю аднаўлення рабочай копіі (update) наколькі магчыма часта (рэальная частата аднаўленняў вызначаецца частатой унясення зменаў, якая залежыць ад актыўнасці распрацоўкі і колькасці распрацоўшчыкаў, а таксама ад часу, які затрачваецца на кожнае аднаўленне — калі яно ялікае, распрацоўшчык вымушаны абмяжоўваць частату аднаўленняў, каб не марнаваць час).
Мадыфікацыя праекта 
Распрацоўшчык мадыфікуе праект, змяняючы яго файлы ў рабочай копіі ў адпаведнасці з праектным заданнем. Гэтая работа выконваецца лакальна і не патрабуе звяртання да сервера VCS.
Фіксацыя зменаў 
Скончыўшы чарговы этап работы над заданнем, распрацоўшчык фіксуе (commit) свае змены, перадаючы іх на сервер (ці ў асноўную галіну, калі работа над заданнем поўнасцю скончана, алюбо ў асобную галіну распрацоўкі задання). VCS можа патрабаваць ад распрацоўшчыка перад фіксацыяй абавязкова выканаць аднаўленне рабочай копіі. Пры наяўнасці ў сістэме падтрымкі адкладзеных зменаў (shelving), змены могуць быць пераданы на сервер без фіксацыі. Калі зацверджаная палітыка работы VCS гэта дазваляе, то фіксацыя зменаў можа праводзіцца не штодзённа, а толькі па завяршэнні работы над заданнем; у гэтым выпадку да завяршэння работы ўсе звязаныя з заданнем змены захоўваюцца толькі ў лакальнай рабочай копіі распрацоўшчыка.

Галінаванні[правіць | правіць зыходнік]

Рабіць дробныя выпраўлення ў праекце можна шляхам непасрэднай праўкі рабочай копіі і паслядоўнай фіксацыяй зменаў наўпрост у галоўнай галіне (ствале) на серверы. Аднак пры выконванні сколькі-небудзь значных па аб'ёму работ такі парадак становіцца нязручным: адсутнасць фіксацыі прамежкавых зменаў на серверы не дазваляе працаваць над чым-небудзь у групавым рэжыме, акрамя таго, падвышаецца рызыка страты зменаў пры лакальных аварыях і губляецца магчымасць аналіза і вяртання да папярэдніх варыянтаў кода ў межах дадзенай работы. Таму для такіх зменаў звычайнай практыкай з'яўляецца стварэнне галіны (branch), распрацоўка ў якой вядзецца паралельна са зменамі ў асноўнай версіі. Галіна ствараецца спецыяльнай камандай. Рабочая копія галіны можа быць створана наноў звычайным чынам (камандай атрымання рабочай копіі, з указаннем адраса ці ідэнтыфікатара галіны), альбо шляхам пераключэння наяўнай рабочей копіі на заданую галіну.

Базавы рабочы цыкл пры ужыванні галінаў застаецца такім жа, як і ў агульным выпадку: распрацоўшчык перыядычна аднаўляе рабочую копію (калі з галінай працуе больш аднаго чалавека) і фіксуе ў ёй сваю штодзёную працу. Часам галіна распрацоўкі так і застаецца самастойнай (калі змена нараджае новы вырыянт праекта, які далей развіваецца асобна ад асноўнага), але часцей за ўсё, калі работа, для якой створана галіна, выканана, галіна рэінтэгруецца ў ствол (асноўную галіну). Гэта можа рабіцца камандай зліцця (звычайна merge), альбо шляхам стварэння патча (patch), які змяшчае ўнесеныя падчас распрацоўкі галіны змены і ўжыванні гэтага патча да бягучай асноўнай версіі праекта.

Зліццё версій[правіць | правіць зыходнік]

Тры віды аперацый, якія выконваюцца ў сістэме кіравання версіямі, могуць прыводзіць да неабходнасці аб'яднання зменаў. Гэта:

  • Аднаўленне рабочай копіі (змены, якія зроблены ў асноўнай версіі, зліваюцца з лакальнымі).
  • Фіксацыя зменаў (лакальныя змены зліваюцца са зменамі, якія ўжо зафіксаваны ў асноўнай версіі).
  • Зліццё галін (змены, якія зроблены ў адной галіне распрацоўкі, зліваюцца са зменамі, якія зроблены ў іншай).

Ва ўсіх выпадках сітуацыя прынцыпіяльна аднолькавая і мае наступныя характэрныя рысы:

  1. Раней была зроблена копія дрэва файлаў і каталогаў рэпазітара ці яго часткі.
  2. У далейшым і ў арыгінальнаяе дрэва і ў копію былі незалежна ўнесены некаторыя змены.
  3. Патрабуецца аб'яднаць змены ў арыгінале і копіі такім чынам, каб не парушыць лагічную звязанасць праекта і не страціць даныя.

Цалкам відавочна, што пры невыкананні ўмовы (2) (гэта значыць калі змены былі ўнесены толькі ў арыгінал ці толькі ў копію) аб'яднанне элементарнае — дастаткова скапіяваць змененую частку туды, дзе зменаў не было. У адваротным выпадку зліццё зменаў пераўтвараецца ў нетрывіяльню задачу, у шматлікіх выпадках патрабуе ўмяшання распрацоўшчыка. У цэлым механізм аўтаматычнага зліцця зменаў працуе, засноўваючыся на наступных прынцыпах:

  • Змены могуць палягаць ў мадыфікацыі зместа файла, стварэнні новага файла ці каталога, выдаленні ці перайменаванні файла ці каталога, які існаваў раней у праекце.
  • Калі две змены належаць да розных і не звязаным паміж сабой файлаў і/ці каталогаў, яны заўсёды могуць быць аб'яднаны аўтаматычна. Іх з'яднанне палягае ў тым, што змены, якія зроблены ў кожнай версіі праекта, капіююцца ў выніковую версію.
  • Стварэнне, выдаленне і перайменаванне файлаў у каталогах праекта могуць быць аб'яднаны аўтаматычна, калі толькі яны не канфліктуюць паміж сабой. У гэтым выпадку змены, зробленыя ў кожнай версіі праекта, будуць якапіяваны ў выніковую версію. Канфліктнымі звычайна з'яўляюцца:
    • Выдаленне і змяненне аднаго і таго ж файла ці каталога.
    • Выдаленне і перайменаванне адного і таго ж файла ці каталога (у выпадку, калі сістэма падтрымлівае аперацыю перайменавання).
    • Стварэнне ў розных версіях файла з аднім і тым жа імём і розным зместам.
  • Змены ў межах аднаго тэкставага файла, зробленыя ў розных версіях, могуць быць аб'яднаны, калі яны знаходзяцца ў розных месцах гэтага файла і не перасякаюцца. У гэтым выпадку ў выніковую версію ўносяцца ўсе зробленыя змены.
  • Змены ў межах аднаго файла, калі ён не з'яўляецца тэкставым, заўсёды з'яўляюцца канфліктнымі і не могуць быць аб'яднаны аўтаматычна.

Ва ўсіх выпадках базавой версіяй для зліцця з'яўляецца версія, ў якой было зроблена падзяленне зліваемых версій. Калі гэта аперацыя фіксацыі зменаў, то базавай версіяй будзе версія апошняга аднаўлення перад фіксацыяй, калі аднаўленне — то версія папярэдняга аднаўлення, калі зліянне галінаў — то версія, у якой была створана адпаведнай галіна. Адпаведна, супастаўнымі наборамі зменаў будуць наборы зменаў, зробленых ад базавай да бягучай версіі ва ўсіх аб'ядноўваемых варыянтах.

Абсалютная большасць сучасных сістэм кіравання версіямі арыентавана, у першую чаргу, на праекты распрацоўкі праграмнага забяспечання, у якіх асноўным відам зместа файла з'яўляецца тэкст. Адпаведна, механізмы аўтаматычнага зліцця зменаў арыентуююца на апрацоўку тэкставых файлаў, гэта значыць файлаў, якія змяшчаюць тэкст, які складаецца з радкоў літара-лічбавых сімвалаў, прабелаў і табуляцый, падзеленых сімваламі пераводу радка.

Пры вызначэнні дапушчальнасці зліцця зменаў у межах аднаго і таго ж тэкставага файла працые тыповы механізм шторадковага параўнання тэкстаў (прыкладам яго рэалізацыі з'яўляецца сістэмная ўтыліты GNU diff), які параўноўвае аб'днальныя версіі з базавай і стварае спіс зменаў, гэта значыць даданых, выдаленых і змененых набораў радкоў. Мінімальнвй адзінкай даных для гэтага алгарытма з'яўляецца радок, нават самае дробнае адрозненне робіць радкі рознымі. З улікам таго, што сімвалы-падзяляльнікі, у большасці выпадкаў, не нясуць асэнсаванвй нагрузкі, механізм зліцця можа ігнараваць гэтыя сімвалы пры параўнанні радкоў.

Тыя знойдзенныя наборы змененых радкоў, якія не перасякаюцца паміж сабой, лічацца сумеснымі і іх зліццё робіцца аўтаматычна. Калі ў файлах, якія зліваюцца, знаходзяцца змены, якія закранаюць адзін і той жа радок файла, гэта прыводзіць да канфлікта. Такія файлы могуць быць аб'яднаныя толькі ўручную. Любыя файлы, акрамя тэкставых, з пункту гледжання VCS з'яўляюцца бінарнымі і не дазваляюць аўтаматычнага зліцця.

Канфлікты і іх вырашэнне[правіць | правіць зыходнік]

Сітуацыя, калі пры зліцці некалькіх версій зробленыя ў іх змены перасякаюцца паміж сабой, завецца канфліктам. Пры канфлікце зменаў сістэма кіравання версіямі не можа аўтаматычна стварыць выніковы праект і вымушана звярнуцца да распрацоўшчыка. Як ужо абмяркоўвалася вышэй, канфлікты могуць узнікаць на этапах фіксацыі зменаў, аднаўлення ці зліцці галінаў. Ва ўсіх выпадках пры выяўленні канфлікта адпаведная аперацыя супыняцца да вырашэння.

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

Канфлікты ў файлавай сістэме вырашаюцца прасцей: там можа канфліктаваць толькі выдаленне файла з адной з іншых аперацый, а парадак файлаў у каталоге не мае значэння, так што распрацоўшчыку застаецца толькі абраць, якую аперацыю патрэбна захаваць ў выніковай версіі.

Блакіроўкі[правіць | правіць зыходнік]

Механізм блакіроўкі дазваляе аднаму з распрацоўнікаў захапіць у манапольнае ўжыванне файл ці групу файлаў для ўнясення ў іх зменаў. На той час, пакуль файл заблакаваны, ён застаецца даступным усім астатнім распрацоўшчыкам толькі для чытання, і любая спроба ўнесці ў яго змены адкідаецца серверам. Тэхнічна блакіроўка можа быць арганізавана па-рознаму. Тыповым для сучасных сістэм з'яўляецца наступны механізм.

  • Файлы, для работы з якімі патрабуецца блакіроўка, пазначаюцца спецыяльным флагам «блакаваны». Такая пазнака можа ставіцца аўтаматычна падчас дадання файла ў праект, звычайна для гэтага папярэдне ствараецца спіс масак імёнаў файлаў, якія пры даданні павінны станавіцца блакванымі.
  • Калі файл пазначаны як блакаваны, то падчас вымання рабочай копіі з сервера ён атрымоўвае ў лакальнай файлавай сістэме атрыбут «толькі для чытання», што замінае яго выпадковаму рэдактаванню.
  • Распрацоўнік, які жадае змяніць блакаваны файл, выклікае спецыяльную каманду блакіроўкі (lock) з указаннем імя гэтага файла. У выніку работы гэтай каманды адбываецца наступнае:
    1. сервер правярае, ці не заблакаваны ўжо файл іншым распрацоўнікам; калі гэта так, то каманда блакавання завяршаецца з памылкай «файл заблакаваны іншым карыстальнікам» і распрацоўнік, які выклікаў яе, павінен чакаць, пакуль другі карыстльнік не зніме сваю бакіроўку;
    2. файл на серверы пазначаецца як «блакаваны», з захоўваннем ідэнтыфікатара распрацоўніка і часу блакіроўкі;
    3. калі блакіроўка на серверы прайшла паспяхова, у лакальнай файлавай сістэме з файла рабочай копіі здымаецца атрыбут «толькі для чытання», што дазваляе пачаць яго рэдактаванне[1].
  • Распрацоўнік працуе з заблакаваным файлам. Калі падчас работы высвятляецца, што файл змяняць не трэба, ён можа выклікаць каманду зняцця блакіроўкі (unlock, release lock). Усе змены файла будуць адменены, лакальны файл вернецца ў стан «толькі для чытання», з файла на серверы будзе сняты атрыбут «заблакаваны» і іншыя распрацоўнікі атрымаюць магчымасць змяняць гэты файл.
  • Пры завяршэнні работы з блакаваным файлам распрацоўшчык фіксуе змены. Звычайна блакіроўка пры гэтым знімаецца аўтаматычна, хоць у некаторых сістэмах блакіроўку патрабуецца здымаць уручную пасля фіксацыі, альбо ўказваць у камандзе фіксацыі зменаў адпаведны параметр. Так ці інакш, пры гэтым файл пасля зменаў страчвае флаг «заблакаваны» і можа быць зменены іншымі распрацоўнікамі.

Масавае ужыванне блакіровак, калі ўсе ці большасць файлаў у праекце з'яўляюцца блакаванымі і для любых зменаў неабходна заблакаваць адпаведны набор файлаў, завецца стратэгіяй «блакаванага вымання».[2] Раннія сістэмы кіравання версіямі падтрымлівалі выключна гэтую стратэгію, прадухіляючы такім чынам з'яўленне канфліктаў на корані. У сучасных VCS пераважным з'яўляецца ужыванне няблакавальных выманняў, блакоўкі ж лічацца хутчэй непазбежным злом, якое патрэбна па магчымасці абмяжоўваць. Недахопы ўжывання блакіровак відавочныя:

  • Блакіроўкі наўпрост замінаюць прадуктыўнай працы, паколькі вымушаюць чакаць вызвалення блакаваных файлаў, хоць у большасці выпадкаў нават сумесныя змены адных і тых жа файлаў, якія робяцца падчас розных па сэнсу работ, не перасякаюцца і аб'ядноўваюцца пры зліцці аўтаматычна.
  • Частата ўзнікнення канфліктаў і складанасць іх вырашэння ў большасці выпадкаў не настолькі вялікія, каб стварыць сур'ёзныя цяжкасці. Узнікненне ж сур'ёзнага канфлікта зменаў часцей усяго сігналізуе альбо аб існаванні разыходжанняў у меркаваннях розных распрацоўнікаў адносна дызайна аднаго і таго ж фрагмента, альбо аб няправільнай арганізацыі работы (калі два ці больш распрацоўніка робяць адно і тое ж).
  • Блакіроўкі ствараюць адміністратыўныя праблемы. Тыповы прыклад: распрацоўнік можа забыцца зняць блакіроўку з занятых ім файлаў, сыходзячы ў адпачынах. Дзеля вырашэння падобных праблем даводзіцца выкарыстоўваць адміністратыўныя меры, у тым ліку ўключаць у сістэму тэхнічныя сродкі для скіду нядзейных блакіровак, але і пры іх наяўнасці на навядзенне парадку марнуецца час.

З другога боку, у некаторых выпадках ужыванне блакіровак цалкам апраўдана. Відавочным прыкладам з'яўляецца арганізацыя работы з бінарнымі файлами, для якіх няма інструментальных сродкаў зліцця зменаў альбо такое зліццё прынцыпова немагчыма (як, напрыклад, для файлаў выяў). Калі аўтаматычнае зліццё немагчыма, то пры звычайным парадку работы любая паралельная змена падобных файлаў будзе прыводзіць да канфлікту. У дадзеным выпадку зручней зрабіць такі файл блакаваным, каб гарантаваць, што любыя змены ў яго будуць уносіцца толькі паслядоўна.

Версіі праекта, тэгі[правіць | правіць зыходнік]

Сістэма кіравання версіямі забяспечвае захоўванне ўсіх былых варыянтаў файлаў і, як следства, усіх варыянтаў праекта ў цэлым, якія мелі месца з моманта пачатку яго распрацоўкі. Але само паняцце «версіі» ў розных сістэмах можа тлумачыцца двума рознымі спосабамі.

Адны сістэмы падтрымліваюць версійнасць файлаў. Гэта значыць, што любы файл, які існуе ў праекце, атрымолівае асабісты нумар версіі (звычайна — нумер 1, умоўнай «нулёвай» версіяй файла лічыцца пусты файл з тым жа імём). Пры кожнай фіксацыіі зменаў распрацоўнікам, якія закранаюць файл, адпаведная частка фіксуемых зменаў ужываецца да файла і ён атрымоўвае новы, звычайна наступны па парадку, нумар версіі. Паколькі фіксацыі звычайна закранаюць толькі частку файлаў у рэпазітары, нумары версій файлаў, які існуюць на адзін і той жа момант часу, з цягам часу разыходзяцца, і праект у цэлым (гэта значыць увесь набор файлаў рэпазітара), фактычна, ніякага «нумара версіі» не мае, бо складаецца з мноства файлаў з рознымі нумарамі версій. Падобным чынам працуе, напрыклад, сістэма кіравання версіямі CVS.

Для іншых сістэм паняцце «версія» належыць не асобнаму файлу, а рэпазітару цалкам. Зноў створаны пусты рэпазітар мае версію 1 ці 0, любая фіксацыя зменаў вядзе да павелічэння гэтага нумара (гэта значыць нават пры змяненні аднаго файла на адзін байт увесь рэпазітар лічыцца змененым і атрымоўвае новы нумер версіі). Такім чынам трактуе нумеры версій сістэма Subversion. Нумара версіі асобнага файла тут фактычна не існуе, умоўна можна лічыць такім бягучы нумар версіі рэпазітара (калі лічыць, што пры кожнай змене, унесенай у рэпазітар, усе яго файлы мяняюць нумар версіі, нават тыя, якія не змяняліся). Часам, гаворачы аб «версіі файла» у такіх сістэмах, маюць на ўвазе тую версію рэпазітара, у якой файл быў апошні раз (да патрэбнага моманта) зменены.

Для практычных мэтаў звычайна мае значэнне не асобны файл, а ўвесь праект цалкам. У сістэмах, якія падтрымліваюць версійнасць асобных файлаў, для ідэнтыфікацыі пэўнай версіі праекта можна ужываць дату і час — тады версія праекта будзе складацца з тых версій уваходзячых у яго файлаў, якія меліся ў рэпазітары на названы момант часу. Калі падтрымліваецца версійнасць рэпазітара ў цэлым, нумарам версіі праекта можа лічыцца нумар версіі рэпазітара. Аднак оба варыянта не надта зручныя, так як ні дата, ні нумар версіі рэпазітара звычайна не змяшчаюць інфармацыі аб значных зменах у праекце, аб тым, як доўга і інтэнсіўна над ім працавалі. Для больш зручнай паметкі версій праекта (ці яго частак) сістэмы кіравання версіямі падтрымліваюць паняцце тэгаў.

Тэг (tag) — гэта сімвалічная метка, якая можа быць звязана з пэўнай версіяй файла і/ці каталога ў рэпазітары. З дапамогай адпаведнай каманды ўсім ці частцы файлаў праекта, якія адпавядаюць пэўным умовам (напрыклад, уваходзяць у асноўную версію галоўнай галіны праекта на пэўны момант часу) можа быць прызначана зададзеная метка. Такім чынам можна ідэнтыфікаваць версію праекта (версія «XX.XXX.XXX» — гэта набор версій файлаў рэпазітара, якія маюць тэг «XX.XXX.XXX»), зафіксаваўшы такім чынам яго стан на некаторы пажаданы момант. Як правіла, сістэма тэгаў досыць гнуткая і дазваляе пазначыць адным тэгам і не адначасовыя версіі файлаў і каталогаў. Гэта дазваляе сабраць «версію праекта» любым адвольным чынам. З пункту гледжання карыстальніка сістэмы пазнака тэгамі можа пыглядаць па-рознаму. У некаторых сістэмах яна выяўляецца менавіта як пазнака (тэг можна стварыць, ужыць да пэўных версій файлаў і каталогаў, зняць). У іншых сістэмах (напрыклад, Subversion) тэг уяўляе сабой наўпрост асобны каталог у файлавым дрэве рэпазітара, куды з ствала і галінаў праекта з дапамогай каманды капіявання робяцца копіі патрэбных версій файлаў. Візуальна тэг — гэта проста вынесеная ў асобны каталог копія пэўных версій файлаў рэпазітара. Па ўзгадненню ў дрэве каталогаў, якое адпавядае тэгу, забаронена фіксацыя зменаў (гэта значыць версія праекту, якая прадастаўлецца тэшам, з'яўляецца нязменнай).

Базавыя прынцыпы распрацоўкі ПЗ у VCS[правіць | правіць зыходнік]

Парадак ужывання сістэмы кіравання версіямі ў кожным пэўным выпадку вызначаецца тэхнічным рэгламентам і правіламі, прынятымі ў пэўнай фірме ці арганізацыі, дзе вядзецца праспрацоўка праекту. Тым не меньш, агульныя прынцыпы правільнага ўжывання VCS нешматлікія і адзіныя для любых распрацовак і сістэм кіравання версіямі.

  1. Любыя рабочыя, тэставыя ці дэманстрацыйныя версіі праекту будуюцца толькі з рэпазітара сістэмы. «Персанальныя» пабудовы, якія змяшчаюць пакуль незафіксаваныя змены, могуць рабіць толькі распрацоўшчыкі для мэтаў прамежкавага тэставання. Такім чынам гарантуецца, што рэпазітар змяшчае ўсё патрэбнае для стварэння рабочай версіі праекта.
  2. Бягучая версія галоўнай галіны заўсёды карэктная. Не дапушчальна фіксацыя ў галоўнай галіне няпоўных файлаў ці тых, якія не прайшлі хоць бы папярэдняе тэставанне зменаў. У любы момант пабудова праекта з бягучай версіі павінна быць паспяховай.
  3. Любая значная змена павінна афармляцца як асобная галіна. Прамежкавыя вынікі работы распрацоўніка фіксуюцца ў гэту галіну. Пасля завяршэння працы над зменай галіна аб'ядноўваецца з ствалом. Выключэнні дапускаюцца толькі для дробных зменаў, работа над якімі вядзецца адным распрацоўнікам напрацягу не больш аднаго працоўнага дня.
  4. Версіі праекта пазначаюцца тэгамі. Вылучаная і пазначаная тэгам версія больш ніколі не змяняецца.

Размеркаваныя сістэмы кіравання версіямі[правіць | правіць зыходнік]

Таксама вядомы як англ.: Distributed Version Control System, DVCS. Такія сістэмы ўжываюць размеркаваную мадэль замест традыцыйнай кліент-сервернай. Яны ў агульным выпадку не патрабуюць цэнтралізаванага сховішча: уся гісторыя зменаў дакументаў захоўваецца на кожным камп'ютары, у лакальным сховішчы, і пры патрэбе асобныя фрагменты гісторыі лакальнага сховішча сінхранізуюцца з аналагічным сховішчам на іншым камп'ютары. У некаторых такіх сістэмах лакальнае сховішча змяшчаецца непасрэдна ў каталогах рабочай копіі.

Калі карыстальнік такой сістэмы выконвае звычайныя дзеянні, такія як выманне пэўнай версіі дакумента, стварэнне новай версіі і таму падобнае, ён працуе са сваёй лакальнай копіяй сховішча. Па меры ўнесення зменаў, сховішчы, якія належаць розным распрацоўшчыкам, пачынаюць адрознівацца, і ўзнікае патрэба ў іх сінхранізацыі. Такая сінхранізацыя можа адбывацца з дапамогай абмену патчамі ці так званымі наборамі зменаў (англ.: change sets) паміж карыстальнікамі.

Апісаная мадэль лагічна блізкая да стварэння асобнай галіны для кожнага распрацоўніка ў класічнай сістэме кіраваня версіямі (у некаторых размеркаваных сістэмах перад пачаткам работы з лакальным сховішчам патрэбна стварыць новую галіну). Адрозненне палягае ў тым, што да моманта сінхранізацыі іншыя распрацоўнікі гэтай галіны не бачаць. Пакуль распрацоўнік змяняе толькі сваю галіну, яго праца не ўплывае на іншых удзельнікаў праекта і наадварот. Па сканчэнні адасобленай часткі працы, унесеныя ў галіны змены зліваюць з галоўнай (агульнай) галіной. Як пры зліцці галін, так і пры сінхранізацыі розных сховішч магчымы канфлікты версій. На гэты выпадак ва ўсіх сістэмах прадугледжаны тыя ці іншыя метады выяўлення і вырашэння канфліктаў зліцця.

З пункту гледжання карыстальніка размеркаваная сістэма адрозніваецца патрэбай ствараць лакальны рэпазітар і наяўнасцю ў каманднай мове дзвух дадатковых каманд: каманды атрымання рэпазітара ад аддаленага камп'ютара (pull) і перадачы свайго рэпазітара на аддалены камп'ютар (push). Першая каманда выконвае зліццё зменаў аддаленага і лакальныгы рэпазітара са змяшчэннем выніка ў лакальны рэпазітар; другая — наадварот, выконвае зліццё зменаў двух рэпазітараў са змяшчэннем выніка ў аддалены рэпазітар. Як правіла, каманды зліцця ў размеркаваных сістэмах дазваляюць абраць, якія наборы зменаў будуць перадавацца ў іншы рэпазітар ці вымацца з яго, выпраўляць канфлікты зліцця непасрэдна падчас аперацыі ці пасля яе няўдалага завяршэння, паўтараць ці ўзнаўляць няскончанае зліццё. Звычайна перадача сваіх зменаў у чужы рэпазітар (push) завяршаецца ўдала толькі пры ўмове адсутнасці канфліктаў. Калі канфлікты ўзнікаюць, карыстальнік павінен спачатку зліць версіі ў сваім рэпазітары (выканаць pull), і толькі потым перадаваць іх іншым.

Звычайна рэкамендуецца арганізаваць работу з сістэмай так, каб карыстальнікі заўсёды ці пераважна выконвалі зліццё ва ўласным рэпазітары. Гэта значыць, у адрозненні ад цэнтралізаваных сістэм, дзе карыстальнікі перадаюць свае змены на цэнтральны сервер, калі лічаць патрэбным, у размеркаваных сістэмах больш натуральным з'яўляецца парадак, калі зліццё версій распачынае той, каму патрэбна атрымаць яго вынік(напрыклад, распрацоўнік, які кіруе будовым серверам).

Асноўная перавага размеркаваных сістэм — іх гнуткасць і значна большая (у параўнанні з цэнтралізаванымі сістэмамі) аўтаномія асобнага рабочага месца. Кожны камп'ютар распрацоўніка з'яўляецца фактычна самастойным і паўнавартасным серверам, з такіх камп'ютараў можна пабудаваць адвольную па структуры і ўзроўню складанасці сістэму, задаўшы (як тэхналагічна, так і адміністрацыйнымі мерамі) пажаданы парадак сінхранізацыі. Пры гэтым кожны распрацоўнік можа весці работу незалежна, бо яму зручна, змяняючы і захоўваючы прамежкавыя версіі дакументаў, карыстаючыся ўсімі магчымасцямі сістэмы (у тым ліку доступам да гісторыі зменаў) нават у адсутнасці сеткавага злучэння з серверам. Сувязь з серверам ці іншымі распрацоўнікамі патрабуецца выключна для выканання сінхранізацыі, пры гэтым абмен наборамі зменаў можа ажыццяўляцца па розным схемам.

Да недахопаў размеркаваных сістэм можна аднесці павелічэнне патрабаванага аб'ёма дыскавай памяці: на кожным камп'ютары даводзіцца трымаць поўную гісторыю версій, у той час як у цэнтралізаванай сістэме на камп'ютары распрацоўніка звычайна захоўваецца толькі рабочая копія, толькі зрэз рэпазітара на нейкі момант часу і ўнесеныя змены. Меньш відавочным, але непрыемным недахопам з'яўляецца тое, што ў размеркаванай сістэме практычна немагчыма рэалізаваць некаторыя віды функцыянальнасці, якія падаюць цэнтралізаваныя сістэмы. Гэта:

  • Блакіроўка файла ці групы файлаў (для захоўвання прыкметы блакіроўкі патрэбны агульнадаступны цэнтральны сервер, які няспынна знаходзіцца online). Гэта вымушае ўжыць спецыяльныя адміністратыўныя меры, калі даводзіцца працаваць з бінарнымі файламі, непрыдатнымі для аўтаматычнага зліцця.
  • Сачэнне за пэўным файлам ці групай файлаў (змены файлаў адбываюцца на розных серверах, зліццё і вылучэнне галінаў адбываецца лакальна, аб зменах становіцца вядома толькі падчас сінхранізацыі, прычым не ўсім распрацоўнікам, а толькі тым, хто ўдзельнічае ў гэтай сінхранізацыі).
  • Адзіная скразная нумарацыя версій сістэмы і/ці файлаў, дзе нумар версіі аднастайна узрастае (такая нумарацыя таксама патрабуе наяўнасці галоўнага сервера, які задае нумары версій для ўсіх астатніх). У размеркаваных сістэмах даводзіцца абыходзіцца лакальнымі пазначэннямі версій і ўжываць тэгі, прызначэнне якіх вызначаецца дамовай паміж распрацоўнікамі ці карпаратыўнымі стандартамі фірмы.
  • Лакальная праца карыстальніка з асобнай, невялікай па аб'ёму выбаркай са значнага па памеру і ўнутранай складанасці сховішча на аддаленым серверы.

Можна вызначыць наступныя тыповыя сітуацыі, у якіх ужыванне размеркаванай сітэмы дае заўважныя перавагі:

  • Перыядычная сінхранізацыя некалькіх камп'ютараў пад кіраванне аднаго распрацоўніка (рабочага камп'ютара, хатняга камп'ютара, ноўтбука і інш.). Выкарыстанне размеркаванай сістэмы пазбаўляе ад неабходнасці вылучаць адзін з камп'ютараў у якасці сервера, а сінхранізацыя выконваецца па патрэбе, звычайна пры «перасадцы» распрацоўніка з адной прылады на іншую.
  • Сумесная работа над праектам невялікай тэрытарыяльна размеркаванай групы распрацоўнікаў без вылучэння агульных рэсурсаў. Як і ў папярэднім выпадку, рэалізуецца схема працы без галоўнага сервера, а актуальнасць рэпазітараў падтрымліваецца перыядычнамі сінхранізацыямі па схеме «кожны з кожным».
  • Буйны размеркаваны праект, удзельнікі якога могуць працяглы час працаваць кожны над сваёй часткай, пры гэтым не маюць сталага далучэння да сеціва. Такі праект можа ўжываць цэнтралізаваны сервер, з якім сінхранізуюцца копіі ўсіх яго ўдзельнікаў. Магчымы і больш складаныя варыянты — напрыклад са стварэннем груп для работы па асобным напрамкам унутры больш буйнога праекта. Пры гэтым могуць быць вылучаны асобныя «групавыя» серверы для сінхранізацыі работы груп, тады працэс выніковага зліцця зменаў становіцца дрэвападобным: спачатку асобныя распрацоўшчыкі сінхранізуць змены на груповых серверах, потым адноўленыя рэпазітары груп сінхранізуюцца з галоўным серверам. Магчыма работа і без «групавых» сервераў, тады распрацоўнікі адной групы сінхранізуюць змены паміж сабой, пасля чаго любы з іх (напрыклад, кіраўнік групы) перадае змены на цэнтральны сервер.

У традыцыйнай «офіснай» распрацоўцы праектаў, калі група распрацоўнікаў адносна невялікая і цалкам знаходзіцца на адной тэрыторыі, у межах адзінай лакальнай камп'ютарнай сеткі з увесь час даступнымі серверамі, цэнтралізаваная сістэма можа апынуцца лепшым выбарам з-за сваёй больш жорсткай структуры і наяўнасці функцыянальнасці, якая адсутнічае ў размеркаваных сістэмах. Магчымасць фіксаваць змены без іх зліцця ў цэнтральную галіну ў такіх умовах лёгка рэалізуецца шляхам вылучэння няскончаных работ у асобныя галіны распрацоўкі.

Слоўнік[правіць | правіць зыходнік]

Агульнапрынятай тэрміналогіі не існуе, у розных сістэмах могуць ужывацца розныя назвы для адных і тых жа дзеяў. Ніжэй прыведзены некаторыя з найбольш часта ўжывальных варыянтаў.

branch 
Галіна — накірунак распрацоўкі, незалежны ад іншых. Галіна ўяўляе сабой копію часткі (як правіла, аднаго каталога) сховішча, у якую можна ўносіць свае змены, якія не ўплываюць на іншыя галіны. Дакументы ў розных галіных маюць аднолькавую гісторыю да пункта галінавання і розныя — пасля яе.
changeset, activity 
Набор зменаў. Уяўляе сабой іменаваны шэраг правак, зробленых у лакальнай копіі дзеля нейкай агульнай мэты. У сістэмах, дзе падтрымліваюцца шэрагі правак, распрацоўшчык можа аб'ядноўваць лакальныя праўкі ў групы і выконваць фіксацыю лагічна звязаных зменаў адной камандай, указаўшы патрэбны шэраг правак у якасці параметра. Пры гэтым іншыя праўкі застануцца незафіксаванымі. Тыповы ўзор: вядзецца работа над даданнем новай функцыянальнасці, а ў гэты момант выяўляецца крытычная памылка, кую патрэбна неадкладна выправіць. Распрацоўнік стварае шэраг зменаў для ўжо зробленай працы і новы — для выпраўленняў. Па сканчэнні выпраўлення памылкі выконваецца каманда фіксацыі толькі другога шэрагу правак.
check-in, commit, submit 
Стварэнне новай версіі, фіксацыя зменаў. Распаўсюджванне зменаў, якія зроблены ў рабочай копіі, на сховішча дакументаў. Пры гэтым у сховішчы ствараецца новая версія змененых дакументаў.
check-out, clone 
Выманне дакумента са сховішча і стварэнне рабочай копіі.
conflict 
Канфлікт — сітуацыя, калі некалькі карыстальнікаў зрабілі змены аднаго і таго ж кавалка дакумента. Канфлікт выяўляецца, калі адзін карыстальнік зафіксаваў свае змены, а другі спрабуе зафіксаваць свае, і сістэма сама не здольна карэктна сліць кафліктныя змены. Паколькі праграма можа быць недастаткова разумнай для таго каб вызначыць, якая змена з'яўляецца «карэктнай», другому карыстальніку патрэбна самому вырашыць канфлікт (resolve).
head 
Асноўная версія — самая свежая версія для галіны/ствала, якая знаходзіцца ў сховішчы. Колькі галін, столькі асноўных версій.
merge, integration 
Зліццё — аб'яднанне незалежных зменаў у адзіную версію дакумента. Ажыццяўляецца, калі дзве асобы змянілі адзін і той жа файл ці пры пераносе зменаў з адной галіны ў іншую.
rebase 
Перанос пункту галінавання (версіі, ад якой пачынаецца галіна) на больш познюю версію асноўнай галіны. Напрыклад, пасля выпуску версіі 1.0 праекта ў ствале працягваецца дапрацоўка (выпраўленне памылак, дапрацоўка наяўнага функцыянала), адначасова пачынаецца работа над новай функцыянальнасцю ў новай галіне. Праз нейкі час у галоўнай галіне адбываецца выпуск версіі 1.1 (з выпраўленнямі); зараз пажадана, каб галіна распрацоўкі новага функцыяналу ўключала змены, які адбыліся ў ствале. Гэта можна зрабіць і базавымі сродкамі, з дапамогай зліцця (merge), выдзяліўшы набор зменаў паміж версіямі 1.0 і 1.1 і зліўшы яго ў галіну. Але пры наяўнасці ў сістэме падтрымкі перабазавання галіны гэтая аперацыя робіцца прасцей, адной камандай: па камандзе rebase (з параметрамі: галіной і новай базавай версіяй) сістэма самастойна вызначае патрэбныя наборы зменаў і робіць іх зліццё, пасля чаго для галіны базавай версіяй становіцца версія 1.1; пры наступным зліцці галіны са ствалом сістэма не разглядае паўторна змены, якія былі зроблены паміж версіямі 1.0 і 1.1, так как ветвь логически считается выделенной после версии 1.1.
repository, depot 
Сховішча дакументаў — месца, дзе сістэма кіравання версіямі захоўвае ўсе дакументы разам з гісторыяй іх зменяў і іншай службовай інфармацыяй.
revision 
Версія дакумента. Сістэмы кіравання версіямі адрозніваюць версіі по нумарам, якія прызначаюцца аўтаматычна.
shelving 
Адкладанне зменаў. Магчымасці, якія падаюць некаторыя сістэмы па стварэнні шэрагу зменаў (changeset) і захавання яго на серверы без фіксацыі (commit). Адкладзены набор зменаў даступны для чытання іншым удзельнікам праекту, але да спецыяльнай каманды не ўваходзіць у асноўную каліну. Падтрымка адкладання зменаў дае магчымасць карыстальнікам захоўваць незавершаныя работы на серверы, не ствараючы для гэтага асобных галін.
tag, label 
Метка, якую можна прызначыць пэўнай версіі дакумента. Метка ўяўляе сабой сімвалічнае імя для групы дакументаў, пры гэтым метка апісвае не толькі набор імёнаў файлаў, але і версію кожнага файла. Версіі ўключаных у метку дакументаў могуць належыць розным момантам часу.
trunk, mainline, master 
Ствол — асноўная галіна распрацоўкі праекта. Палітыка работы са ствалом можа адрознівацца ў розных праектах, але ў цэлым яна такая: большасць зменаў уносіцца ў ствол; калі патрабуецца сур'ёзная змена, якая здольна прывесці да нестабільнасці, ствараецца галіна, якая зліваецца са ствалом, калі новаўведзенне будзе ў дастатковай меры выпрабавана; переда выпускам чарговай версіі ствараецца «рэлізная» галіна, у якую ўносяцца толькі спраўленні.
update, sync 
Сінхранізацыя рабочай копіі да некаторага зададзенага стану сховішча. Часцей за ўсё гэтае дзеянне значыць абнаўленне рабочай копіі да самага свежага стану сховішча. Аднак пры неабходнасці можна сінхранізаваць рабочую копію і да больш старога стану, чым бягучае.
working copy 
Рабочая (лакальная) копія дакументаў.

Гл. таксама[правіць | правіць зыходнік]

Зноскі

  1. Зразумела, што ніхто не можа замінаць распрацоўніку зняць атрыбут «толькі для чытання» з лакальнай копіі файла і змяніць яго, але большасць сістэм кіравання версіямі ў такой сітуацыі выклікаюць пры спробе фіксацыі зменаў на серверы памылку тыпа «Файл не быў заблакаваны бягучым карыстальнікам».
  2. CVS. Выбар паміж блакаванымі і неблкаванымі выманнямі.

Спасылкі[правіць | правіць зыходнік]