Системи за контрол над изходния код

Какво правят
Синхронизиране на файлове
Етикети и разклонения
Коя е най-добрата

       Сорс контрол системите са създадени за контрол над изходния код на програмите. С течение на времето еволюират и сега се наричат с по-общото наименование системи за контрол чрез версии (version control systems). Аз като програмист обаче си ги наричам по стария начин.
       Идеята е на едно място (сървър) да се държи изходния код на програмите и много клиенти (програмисти, дизайнери и т.н.) да вземат от там и да слагат там разни файлове. Основната полза от сорс контрол системите е поддържаната от тях информация за история на промените. Историята позволява да вземеш стара версия на файл, да сравниш различни версии на файл, да маркираш или копираш продадени версии на целия изходен код и т.н. В сорс контрол системите няма понятие за директория както във файловите системи. В центъра на сорс контрола са само файловете. Различните системи наричат еквивалентите си на директории от страна на сървъра с различни имена и позволяват различно съпоставяне между тях и реалните директории от страна на клиента. Тук ще използвам понятието директория в интуитивния му смисъл на контейнер за файлове и ще допускам, че йерархията от контейнери за файлове е еднаква от страна на сървръра и на клиента.

Какво правят

       Стандартните операции, които се извършват със сорс контрол системите са:

1. От клиент (програмист) към сървър
   • добвяне на нов файл / директория
   • изтриване на съществуващ файл / директория
   • преименуване или преместване на файл / директория
   • добавяне на нова версия на съществуващ файл - може да се наложи синхронизиране на съдържанието на файла ако някой друг е добавил нова версия на същия файл.
2. От сървър към клиент (програмист)
   • сваляне на последна версия - може да се наложи синхронизиране на съдържанието на файла ако е бил променян от клиента.
   • синхронизиране на директория - изтриват се файлове, които са били изтрити на сървъра, преименуват се и се преместват файлове / директории ако така е станало в сървъра
3. Промяна на състояние на сървъра
   • маркиране на файл за редактиране
   • заключване / отключване на файл - само този който е заключил даден файл може да добавя нови версии
   • слагане на етикет - маркиране на дадено състояние в историята на файлове / директории. Например, когато се счете, че дадена компилация на програмата е стабилна може да се сложи етикет "Stable build (1209)". Ползите от етикетите съм обяснил по-долу.
   • създаване на разклонение в главното развитие на историята на файловете.
   • възстановяване на стара версия на файл да е последната, т.е. отхвърляне на историята след дадена версия.

       Терминологията в различните сорс контрол системи е различна - например сваляне на последна версия за SourceSafe се нарича "get latest version", докато за CVS се нарича "checkout" или "update". За SourceSafe пък "checkout" означава сваляне на последна версия + маркиране за редакция (може да включва и заключване ако файлът е двоичен или сървърът е конфигуриран така). Някои сорс контрол системи са транзакционни, т.е. локалните промени се отразяват на сървъра с една команда. В този случай няколко операции (добавяне, изтриване, преименуване, преместване, качване на версия на файл и т.н.) се обединяват и се изпълняват наведнъж (атомарно) - в команда най-често с името "commit". Ако се провали въпросната "commit" команда - нито една от опреациите в нея не се извършва. Транзакционни са например Perforce, TFS (частта за сорс контрол) и SVN. Споменатите вече по-стари SourceSafe и CVS не са транзакционни.

Синхронизиране на файлове

       Възможни са няколко случая на конфликт на промени върху един и същ файл:

1. При добавяне на промени в сървъра, т.е. при повишаване на версия на файл.

       Да речем сме маркирали за редактирнане файл при версия 14. Ако се опитаме да обновим версията (т.е. да качим на сървъра промените си), новата версия би трябвало да е 15. Конфликтът възниква ако файлът не е заключен и други клиенти (програмисти) са го редактирали и са добавили версии, например 15 и 16.


2. При сваляне на последна версия на файл от сървъра.
• Маркирана е за редактиране по-стара от последната версия на сървъра.
       Да речем сме маркирали за редактирнане файл при версия 14 и сме го променяли. Конфликтът възниква ако се взема последна версия на този файл и на сървъра има версия по-голяма от 14.
       Конфликт няма ако версията на сървъра е 14 - тогава локалните промени са по-нови и не се пипат. Конфликт няма също ако версията на съръвра е например 16, но няма разлика между локалния файл и версия 14. В този случай се сваля версия 16 и маркировката се променя все едно файлът е маркиран за версия 16. Крайният резултат е, че пак има маркиран за редакция файл и пак няма разлика със сървъра.


• Файлът е променян без да е маркиран за редакция (т.нар. "локална версия").

       При всеки конфликт, клиентът (програмистът) решава дали да синхронизира съдържанието на файла с двата вида промени, дали да отхвърли своите промени или дали да отхвърли чуждите промени.

Етикети и разклонения

       Етикетите и разклоненията се използват за различни цели в зависимост от конкретните нужди на клиентите на сорс контрол системата.
       Етикетите са предназначени за групово маркиране на момент в историята на много файлове. Така може да се следят разлики или да се взема версията на файловете към този момент във времето. Към етикетите може да слага коментар, който да описва причината за маркирането. Типичен пример за слагане на етикет е при стабилна компилация на активно променящ се продукт. Слага се етикет на цялото дърво на продукта в момента на стабилност и при последващи счупвания може да се следи какво е променяно спрямо стабилния момент. Също така, при необходимост може да се вземе цялото дърво по етикета и да се има отново стабилен продукт.
       Разклоненията позволяват да се поддържа отделна история на файловете. Просто в даден момент от време се прави копие на файловете и в това копие те започват да имат нова история, независима от тази на оригиналите. Най-често разклонение се прави, когато се пуска продукт на пазара. В главната история се слага работата по следващата версия, а в разклонението се слагат корекции по пуснатия на пазара продукт. Така се улеснява поддръжката на пуснати на пазара стари версии.
       Разбира се, етикети и разклонения се правят и при други практически случаи, различни от дадените типични такива.

Коя е най-добрата

       Трудно е да се каже коя сорс контрол система е най-добра... Всъщност всички имат някакви недомислици или проблеми. Накратко - личното ми мнение е, че от платените най-добър е Perforce, а от безплатните - SVN. Ако се чудите за TFS (SourceSafe в никакъв случай не използвайте) - знайте, че в Microsoft използват SourceDepot, за която се носят слухове, че е модифицирана от Microsoft стара версия на Perforce:
http://www.subversionary.org/propaganda/why-not-vss
http://maillist.perforce.com/pipermail/perforce-user/2004-January/012066.html
http://www.securityoffice.net/mssecrets/other/Startup.htm
       Познайте защо не използват нито SourceSafe, нито TFS! Все пак в бъдеще TFS може да стане и доста добър, защото включва и bug tracking система (следене на грешки). Проблемите, които има със синхронизирането на сорсове от разклонения не са страшни ако знаеш как да се оправяш с тях. Всъщност, причината да не харесвам TFS е само тясната му обвързаност с продуктите на Microsoft (сървърът работи само под Windows и MS SQL, а клиентът се състои само от плъгин за Visual Studio и command-line програма).