1.1 Почеток - За верзиска контрола

Методот за верзиска контрола на многу луѓе е да ги копираат фајловите во друг директориум (можеби директориум со временски печат, ако се паметни). Овој пристап е многу чест затоа што е толку едноставен, но исто така е неверојатно склон на грешки. Лесно е да се заборави во кој директориум сте и случајно да запишете во погрешна датотека или да копирате преку фајлови што не сакате да ги користите.

За да се справат со ова прашање, програмерите одамна развиле локални VCS-и кои имаат едноставна база на податоци која ги зачувува сите промени во фајлови под верзиска контрола.

Една од популарните VCS алатки е системот наречен RCS, кој сеуште е вклучен со многу компјутери денес. RCS работи со одржување на вид на закрпа (разликите помеѓу две состојби) во посебен формат на дискот; тогаш може повторно да се рекреира било кој фајл во било кој момент со додавање или одзимање на закрпите до тој момент.

Следното големо прашање со кое луѓето се соочуваат е дека тие треба да соработуваат со друѓи луѓе. За да се справат со овој проблем, се развија Централизирани верзиски контролни системи (CVCS). Овие системи, како што се CVS, Subversion и Perforce, имаат единствен сервер кој ги содржи сите верзии на фајловите, како и голем број клиенти кои зимаат фајлови од тоа централно место. Многу години веќе, ова е стандард за верзиска контрола.

Многу години веќе, ова е стандард за верзиска контрола.

Ова поставување нуди многу предности, особено во однос на локалните VCS. На пример, сите до одреден степен дознаваат што прават сите други во проектот. Администраторите имаат контрола во вркса со кој што може да го направи, а тоа е далеку полесно да се направи во CVCS отколку да се справи со локалните бази на податоци за секој клиент.

Сепак, ова поставување, исто така, има некои сериозни недостатоци. Најочигледна е единствената точка на неуспех што го претставува централизираниот сервер. Ако тој сервер се спушти за еден час, тогаш за тој час никој воопшто не може да соработува или да ги зачува верзиите на она што тие го работат. Ако хард дискот на кој се наоѓа централната база на податоци станува корумпиран и не се чуваат правилни бекап, вие изгубите апсолутно сè - целата историја на проектот, освен она што се случува на еден поединечен случај на локални машини. Локалните VCS системи страдаат од истиот проблем - секогаш кога ја имате целата историја на проектот на едно место, ризикувате да изгубите сè.

Тука влегуваат системи за контрола на дистрибуирани верзиски контролни системи(DVCSs). Во DVCS (на пример Git, Mercurial, Bazaar или Darcs), клиентите не само што ја проверуваат најновата слика на датотеките, тие целосно го отсликуваат складиштето, вклучувајќи ја целосната историја. Така, ако било кој сервер не е достапен, и овие системи соработувале преку тој сервер, било кое од клиентските складишта може да се копира назад до серверот за да се врати. Секој клон е целосна копија од сите податоци.

Понатаму, многу од овие системи се направени така да може да работат со неколку оддалечени складишта со кои можат да работат, така што можете да соработувате со различни групи на луѓе на различни начини истовремено во рамките на истиот проект. Ова овозможува да поставите неколку типови на работни процеси кои не се можни во централизираните системи, како што се хиерархиски модели.