wd wp Пошук:
    ⬜

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

    Сістэма кіравання версіямі (ад англ.: 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 з’яўляюцца бінарнымі і не дазваляюць аўтаматычнае зліццё.

    Канфлікты і іх вырашэнне

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

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

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

    Блакіроўкі

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

    Масавае ужыванне блакіровак, калі ўсе ці большасць файлаў у праекце з’яўляюцца блакіраванымі і для любых змен неабходна заблакіраваць адпаведны набор файлаў, называецца стратэгіяй «блакіраванага вымання».[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), і толькі потым перадаваць іх іншым.

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

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

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

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

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

    Слоўнік

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

    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. Выбар паміж блакіраванымі і неблакіраванымі выманнямі.(недаступная спасылка)

    Спасылкі

    Тэмы гэтай старонкі (3):
    Катэгорыя·Сістэмы кіравання версіямі
    Катэгорыя·Вікіпедыя·Артыкулы да вікіфікацыі
    Катэгорыя·Вікіпедыя·Артыкулы з непрацоўнымі спасылкамі