Сістэма кіравання версіямі (ад ці ) — праграмнае забеспячэнне для палягчэння работы са зменлівай інфармацыяй. Сістэма кіравання версіямі дазваляе захоўваць некалькі версій аднаго і таго ж дакумента, пры неабходнасці вяртацца да больш ранніх версій, вызначаць, хто і калі зрабіў тую ці іншую змену, і шмат іншага.
Такія сістэмы найбольш шырока ўжываюцца пры распрацоўцы праграмнага забеспячэння для захоўвання зыходных кодаў праграмы, якая распрацоўваецца. Аднак яны могуць з поспехам выкарыстоўвацца і ў іншых праектах, дзе вядзецца работа з вялікай колькасцю няспынна зменлівых электронных дакументаў. У прыватнасці, сістэмы кіравання версіямі выкарыстоўваюцца ў САПР, звычайна ў складзе сістэм кіравання данымі аб вырабах (PDM). Кіраванне версіямі ўжываецца ў інструментах канфігурацыйнага кіравання (Software Configuration Management Tools).
Праграмнае забеспячэнне Вікіпедыі захоўвае гісторыю змен для ўсіх яе артыкулаў, ужываючы метады, аналагічныя тым, якімі карыстаюцца ў сістэмах кіравання версіямі.
Агульныя звесткі
Сітуацыя, у якой электронны дакумент за час свайго існавання зведвае шэраг змен, з'яўляецца даволі тыповай. Пры гэтым часта бывае важна мець не толькі апошнюю версію, але і некалькі папярэдніх. У найпрасцейшым выпадку можна проста захоўваць некалькі варыянтаў дакумента, нумаруючы іх адпаведным чынам. Такі спосаб неэфектыўны (даводзіцца захоўваць некалькі амаль ідэнтычных копій), патрабуе больш увагі і дысцыпліны і часта вядзе да памылак, таму былі распрацаваны сродкі для аўтаматызацыі гэтай работы.
Традыцыйныя сістэмы кіравання версіямі ўжываюць цэнтралізаваную мадэль, калі маецца адзінае сховішча дакументаў, якое кіруецца спецыяльным серверам, які і выконвае большую частку функцый кіравання версіямі. Карыстальнік, які працуе з дакументамі, павінен спачатку атрымаць патрэбную яму версію дакумента са сховішча; звычайна ствараецца лакальная копія дакумента, т. зв. «рабочая копія». Можа быць атрымана апошняя версія ці любая з папярэдніх, якая можа быць абрана па нумару версіі ці даце стварэння, альбо па іншых прызнаках. Пасля таго, як у дакумент унесены патрэбныя змены, новая версія змяшчаецца ў сховішча. У адрозненне ад простага захоўвання файла, папярэдняя версія не знішчаецца, а таксама застаецца ў сховішчы і можа быць атрымана адтуль у любы час. Сервер можа ўжываць т. зв. дэльта-кампрэсію — гэта такі спосаб захоўвання дакументаў, пры якім захоўваюцца толькі змены паміж паслядоўнымі версіямі, што дазваляе паменшыць аб'ём даных у сховішчы. Улічваючы, што звычайна найбольш запатрабаванай з'яўляецца апошняя версія файла, сістэма можа пры захоўванні новай версіі захоўваць яе цалкам, замяняючы ў сховішчы апошнюю раней захаваную версію на розніцу паміж гэтай і свежай версіяй. Некаторыя сістэмы (напрыклад, ClearCase) падтрымліваюць захоўванне версій абодвух відаў: большасць версій захоўваецца ў выглядзе дэльта, але перыядычна (па спецыяльнай камандзе адміністратара) выконваецца захоўванне версій усіх файлаў у поўным выглядзе; такі падыход забяспечвае максімальна поўнае аднаўленне гісторыі ў выпадку пашкоджання рэпазіторыя.
Часам стварэнне новай версіі выконваецца незаўважна для карыстальніка (празрыста), альбо прыкладной праграмай, якая мае ўбудаваную падтрымку такой функцыі, альбо за кошт ужывання спецыяльнай файлавай сістэмы. У гэтым выпадку карыстальнік проста працуе з файлам, як звычайна, і падчас захоўвання файла аўтаматычна ствараецца новая версія.
Звычайнай з'яўляецца сітуацыя, калі над адным праектам працуюць адначасова некалькі чалавек. Калі два чалавекі змяняюць адзін і той жа , то адзін з іх можа выпадкова адмяніць змены, зробленыя другім. Сістэмы кіравання версіямі адсочваюць такія канфлікты і прапаноўваюць сродкі іх вырашэння. Большасць сістэм можа аўтаматычна аб'ядноўваць (зліваць) змены, зробленыя рознымі распрацоўшчыкамі. Аднак такое аўтаматычнае аб'яднанне змен звычайна магчыма толькі для тэкставых файлаў і пры ўмове, што змяняліся розныя часткі (якія не перасякаюцца) гэтага файла. Такое абмежаванне звязана з тым, што большасць сістэм кіравання версіямі арыентавана на падтрымку працэсу распрацоўкі праграмнага забеспячэння, а зыходныя коды праграм захоўваюцца ў тэкставых файлах. Калі аўтаматычнае аб'яднанне выканаць не ўдалося, сістэма можа прапанаваць вырашыць праблему ўручную.
Часта выканаць зліццё немагчыма ні ў аўтаматычным, ні ў ручным рэжыме, напрыклад, калі фармат файла невядомы ці занадта складаны. Некаторыя сістэмы кіравання версіямі даюць магчымасць заблакіраваць файл у сховішчы. Блакіроўка не дазваляе іншым карыстальнікам атрымаць рабочую копію або забараняе змены рабочай копіі файла (напрыклад, сродкамі файлавай сістэмы) і забяспечвае такім чынам выключны доступ толькі таму карыстальніку, які працуе з дакументам.
Многія сістэмы кіравання версіямі даюць шэраг іншых магчымасцей: Дазваляюць ствараць розныя варыянты аднаго дакумента, г. зн. галіны, з агульнай гісторыяй змен да пункта разгалінавання і з рознымі — пасля яе. Даюць магчымасць даведацца, хто і калі дадаў або змяніў пэўны набор радкоў у файле. Вядуць журнал змен, у якім карыстальнікі могуць запісваць тлумачэнні аб тым, што і чаму яны змянілі ў дадзенай версіі. Кантралююць правы доступу карыстальнікаў, дазваляючы ці забараняючы чытанне ці змены даных, у залежнасці ад таго, хто запытвае гэтае дзеянне.
Тыповы парадак работы з сістэмай
Кожная сістэма кіравання версіямі мае свае спецыфічныя асаблівасці ў наборы каманд, парадку работы карыстальнікаў і адміністраванні. Між тым, агульны парадак работы для большасці VCS цалкам стэрэатыпны. Дапусцім, што праект, якім бы ён ні быў, ужо існуе і на серверы размешчаны яго рэпазіторый, да якога распрацоўшчык атрымлівае доступ.
Пачатак работы з праектам
Першым дзеяннем, якое павінен выканаць распрацоўшчык, з'яўляецца атрыманне рабочай копіі праекта ці той яго часткі, з якой належыць працаваць. Гэтае дзеянне выконваюць з дапамогай стандартнай каманды атрымання версіі (checkout або clone) альбо спецыяльнай каманды, якая фактычна выконвае тое ж самае дзеянне. Распрацоўшчык задае версію, якая павінна быць скапіравана, звычайна капіруецца апошняя (або абраная адміністратарам у якасці асноўнай) версія.
Па камандзе атрымання ўсталёўваецца злучэнне з серверам і праект (ці яго частка — адзін з каталогаў з падкаталогамі) у выглядзе дрэва каталогаў і файлаў капіруецца на камп'ютар распрацоўшчыка. Звычайнай практыкай з'яўляецца дубліраванне рабочай копіі: апроч асноўнага каталога з праектам на лакальны дыск (альбо ў асобны, спецыяльна абраны каталог, альбо ў сістэмныя падкаталогі асноўнага дрэва праекта) дадаткова запісваецца яшчэ адна яго копія. Працуючы з праектам, распрацоўшчык змяняе толькі файлы асноўнай рабочай копіі. Другая лакальная копія захоўваецца ў якасці эталона, дазваляючы ў любы момант без звяртання да сервера вызначыць, якія змены былі ўнесены ў пэўны файл або праект у цэлым і ад якой версіі была «адгалінавана» рабочая копія; як правіла, любая спроба ручной змены гэтай копіі вядзе да памылак у рабоце праграмнага забеспячэння VCS.
Штодзённы цыкл работы
Пры некаторых варыяцыях, вызначаных асаблівасцямі сістэмы і дэталямі прынятага бізнес-працэсу, звычайны цыкл работы распрацоўшчыка на працягу дня выглядае наступным чынам.
Абнаўленне рабочай копіі Па меры ўнясення змен у праект рабочая копія на камп'ютары распрацоўшчыка старэе, разыходжанне яе з асноўнай версіяй праекта павялічваецца. Гэта павышае рызыку ўзнікнення канфліктных змен (гл. ніжэй). Таму зручна падтрымліваць рабочую копію ў стане, максімальна блізкім да бягучай асноўнай версіі, дзеля чаго распрацоўшчык выконвае аперацыю абнаўлення рабочай копіі (update) наколькі магчыма часта (рэальная частата абнаўленняў вызначаецца частатой унясення змен, якая залежыць ад актыўнасці распрацоўкі і колькасці распрацоўшчыкаў, а таксама ад часу, які затрачваецца на кожнае абнаўленне — калі ён вялікі, распрацоўшчык вымушаны абмяжоўваць частату абнаўленняў, каб не марнаваць час). Мадыфікацыя праекта Распрацоўшчык мадыфікуе праект, змяняючы яго файлы ў рабочай копіі ў адпаведнасці з праектным заданнем. Гэтая работа выконваецца лакальна і не патрабуе звяртання да сервера VCS. Фіксацыя змен Скончыўшы чарговы этап работы над заданнем, распрацоўшчык фіксуе (commit) свае змены, перадаючы іх на сервер (ці ў асноўную галіну, калі работа над заданнем поўнасцю скончана, альбо ў асобную галіну распрацоўкі задання). VCS можа патрабаваць ад распрацоўшчыка перад фіксацыяй абавязкова выканаць абнаўленне рабочай копіі. Пры наяўнасці ў сістэме падтрымкі адкладзеных змен (shelving), змены могуць быць перададзены на сервер без фіксацыі. Калі зацверджаная палітыка работы VCS гэта дазваляе, фіксацыя змен можа праводзіцца не штодзённа, а толькі па завяршэнні работы над заданнем; у гэтым выпадку да завяршэння работы ўсе звязаныя з заданнем змены захоўваюцца толькі ў лакальнай рабочай копіі распрацоўшчыка.
Галінаванні
Рабіць дробныя выпраўленні ў праекце можна шляхам непасрэднай праўкі рабочай копіі з паслядоўнай фіксацыяй змен прама ў галоўнай галіне (ствале) на серверы. Аднак пры выкананні колькі-небудзь значных па аб'ёме работ такі парадак становіцца нязручным: адсутнасць фіксацыі прамежкавых змен на серверы не дазваляе працаваць над чым-небудзь у групавым рэжыме, акрамя таго, павышаецца рызыка страты змен пры лакальных аварыях і губляецца магчымасць аналізу і вяртання да папярэдніх варыянтаў кода ў межах дадзенай работы. Таму для такіх змен звычайнай практыкай з'яўляецца стварэнне галіны (branch), распрацоўка ў якой вядзецца паралельна са зменамі ў асноўнай версіі. Галіна ствараецца спецыяльнай камандай. Рабочая копія галіны можа быць створана нанова звычайным чынам (камандай атрымання рабочай копіі, з указаннем адраса ці ідэнтыфікатара галіны), альбо шляхам пераключэння наяўнай рабочай копіі на заданую галіну.
Базавы рабочы цыкл пры выкарыстанні галін застаецца такім жа, як і ў агульным выпадку: распрацоўшчык перыядычна абнаўляе рабочую копію (калі з галінай працуе больш чым адзін чалавек) і фіксуе ў ёй сваю штодзённую працу. Часам галіна распрацоўкі так і застаецца самастойнай (калі змена нараджае новы варыянт праекта, які далей развіваецца асобна ад асноўнага), але часцей за ўсё, калі работа, для якой створана галіна, выканана, галіна ўключаецца ў ствол (асноўную галіну). Гэта можа рабіцца камандай зліцця (звычайна merge), альбо шляхам стварэння патча (patch), які змяшчае ўнесеныя падчас распрацоўкі галіны змены, і выкарыстання гэтага патча ў бягучай асноўнай версіі праекта.
Зліццё версій
Тры віды аперацый, якія выконваюцца ў сістэме кіравання версіямі, могуць прыводзіць да неабходнасці аб'яднання змен. Гэта:
Абнаўленне рабочай копіі (змены, якія зроблены ў асноўнай версіі, зліваюцца з лакальнымі). Фіксацыя змен (лакальныя змены зліваюцца са зменамі, якія ўжо зафіксаваны ў асноўнай версіі). Зліццё галін (змены, якія зроблены ў адной галіне распрацоўкі, зліваюцца са зменамі, якія зроблены ў іншай).
Ва ўсіх выпадках сітуацыя прынцыпова аднолькавая і мае наступныя характэрныя рысы:
Раней была зроблена копія дрэва файлаў і каталогаў рэпазіторыя або яго часткі. У далейшым і ў арыгінальнае дрэва і ў копію былі незалежна ўнесены некаторыя змены. Патрабуецца аб'яднаць змены ў арыгінале і копіі такім чынам, каб не парушыць лагічную звязанасць праекта і не страціць даныя.
Цалкам відавочна, што пры невыкананні ўмовы (2) (гэта значыць калі змены былі ўнесены толькі ў арыгінал ці толькі ў копію) аб'яднанне элементарнае — дастаткова скапіраваць змененую частку туды, дзе змен не было. У адваротным выпадку зліццё змен ператвараецца ў нетрывіяльную задачу, у многіх выпадках патрабуе ўмяшання распрацоўшчыка. У цэлым механізм аўтаматычнага зліцця змен працуе, засноўваючыся на наступных прынцыпах:
Змены могуць заключацца ў мадыфікацыі зместу файла, стварэнні новага файла або каталога, выдаленні ці перайменаванні файла або каталога, які існаваў раней у праекце.