Работа с Mercurial по хостинг - Техническа поддръжка
Тази статия обсъжда използването на Mercurial VCS при хостинг. Системата за контрол на версиите на Mercurial ще ви помогне да управлявате разработката и поддръжката на вашите проекти.
Mercurial е разпределена система за контрол на версиите. Исторически, по-„традиционният“ подход към системите за контрол на версиите е използването на централизирани системи като Subversion.
Както следва от определението, основната разлика между Mercurial и централизираните системи за контрол на версиите е именно разпространението или липсата на единно централно хранилище. Обмислете разликата между централизирания и разпределения подход в системите за контрол на версиите, като използвате примера на Subversion и Mercurial.
Разлики между централизирани и разпределени системи за контрол на версиите в примери
Как един разработчик работи с хранилище в Subversion? Разработчикът изисква текущия фрагмент („работно копие“) на кода от централното хранилище и започва да работи с него. След завършване на въвеждането на всякакви корекции в кода, които представляват логически завършена промяна в софтуера, който се разработва, разработчикът извършва така наречения „commit“ – транзакцията за извършване на промените, направени в централното хранилище, след което текущото „работно копие“ (trunk от гледна точка на Subversion) на хранилището става кодът с корекциите, направени в него на етапа на ангажиране.
В Mercurial работата на разработчика с хранилището е значително различна. Да приемем, че нов разработчик получи достъп до хранилището на Mercurial, разположено в проекта (получаването може да бъде не само от хранилище на споделен сървър, но повече за това по-долу). Той извършва операцията по клониране на хранилището, като в допълнение към текущото работно копие, той получава на свое разположение пълно копие на всичкохранилище с историята на всеки файл. Разработчикът прави определени промени в кода, време е да запази промените в хранилището и той извършва „комит“, но транзакцията е ангажирана към неговото локално копие на хранилището. За да прехвърлите направените от него редакции в локалното хранилище в хранилището на сървъра, трябва да изпълните още една команда - прехвърляне на промените между локалното и отдалеченото хранилище.
На пръв поглед този подход може да изглежда като много излишни стъпки за извършване на промени и наличието на пълно копие на хранилището може да бъде объркващо. В действителност това изобщо не е така. Обмислете случаите, в които наличието на локално хранилище осигурява ясни предимства пред централно хранилище:
Възможност за извършване на „малки“ ангажименти : Да приемем, че разработчикът е направил някаква промяна в кода, която според него заслужава да бъде ангажирана с него, но направените промени все още не могат да се нарекат холистична промяна в кода на проекта, така че ангажирането към основното публично хранилище не е желателно. В случая на Subversion, разработчикът е принуден да откаже да извърши такъв ангажимент и няма способността да прави атомарни промени в своя работен код с възможност за лесно връщане назад. Отчасти този проблем може да бъде решен чрез създаване на отделен клон на кода, но това далеч не винаги е оправдано. В случай на разпределени системи за контрол на версиите (Mercurial), разработчикът просто прави толкова ангажименти към локалното хранилище, колкото му е необходимо (връщане назад, ако е необходимо), тоест той има повече свобода за изпитания и експерименти. Когато разработчикът реши, че направените промени вече представляват холистична модификация на работния проект, той извършва една транзакция, копирайки всички промени, които е направил от локалното хранилище вобщ.
Не е необходимо да имате постоянен достъп до основното хранилище : независимо от мрежовия достъп в случай на разпределени системи за контрол на версиите, разработчикът има на свое разположение пълно копие на хранилището с възможност за извършване на ангажименти, връщане назад, преглед на историята на промените, създаване на нови клонове и т.н.
Разпространението също предполаганеизискване на главно хранилище. Да приемем, че сървърът хоства публично хранилище, споделено от множество разработчици. Един от тях започна работа по внедряването на някаква нова функционалност в проекта, но промяната все още не е завършена и не е желателно да се прави в публичното хранилище. Друг разработчик се заинтересува от разработката, готов да бъде първият, който ще помогне в нейното внедряване. В случай на разпределена система за контрол на версиите (Mercurial), за да може вторият разработчик да получи разработките на първия (които все още не са в общото хранилище), той просто трябва да изпълни заявка, за да получи промените от хранилището на първия разработчик в неговото локално хранилище. Или, алтернативно, инициативата може да дойде от първия разработчик и той може да извърши необходимите промени в хранилището на втория разработчик вместо в основното хранилище. Докато продължават да работят заедно по нова функционалност, и двамата разработчици периодично прехвърлят направените промени между техните хранилища. Когато работата по кода приключи, достатъчно е един от тях просто да изпълни транзакция, за да прехвърли всички натрупани промени в общо хранилище. При такъв модел на работа „основното“ хранилище може изобщо да не съществува и всички промени могат да се прехвърлят между хранилищата на разработчиците, подобно на схемата за трансфер на информация в p2p (peer-to-peer) мрежи.
Основни команди за работа с Mercurial
Разработчиците, които имат опит със Subversion, ще намерят принципите на взаимодействие с Mercurial познати по много начини. Точно като Subversion, Mercurial използва една програма, hg, за извършване на всички действия в хранилище. За извършване на всяко действие с хранилището на тази програма се дава специфична команда, ако е необходимо, допълнена със съответните параметри. По-долу са някои основни команди за работа с хранилища.
Създаване на хранилище
Изпълнението на тази команда в текущата (празна) директория ще създаде там празно хранилище на Mercurial. Може да се направи и като hg init directory_name, което ще създаде необходимата директория и ще инициализира празно хранилище в нея.
Клониране на хранилище
Създава копие на хранилището в указаната директория. Може да се използва както за създаване на локално копие на отдалечено хранилище, така и за създаване на копие на локално хранилище за прилагане на някаква нова функция (в някои случаи наличието на отделно хранилище може да е за предпочитане пред отделен клон в рамките на същото хранилище).
Проверка на набор от промени в локално хранилище
Pull - буквално "дърпам", "дърпам". Изпълнена в директорията с локалното хранилище, тази команда ще копира всички липсващи промени в локалното хранилище от изходното хранилище. Ако хранилището е клонирано от друго, тогава командата може да бъде съкратена до hg pull, което ще вземе същото хранилище като предишното изтегляне като източник. Важно е да разберете, че изпълнението на тази команда само актуализира хронологията на промените в хранилището, докато работното копие остава непокътнато. За да го актуализирате, използвайте следната команда.
Актуализацияработно копие на кода
Актуализира работното копие на кода до най-новата версия. Обикновено се прави след изтегляне на набор от промени от друго хранилище (hg pull). Може също да се използва за получаване на работно копие от всяка определена ревизия.
Записване на промени, направени в хранилището
Ангажира модификациите, направени в работното копие, в хранилището, създавайки отделна ревизия (версия). По подразбиране хранилището ще бъде актуализирано за всички файлове, управлявани от mercurial; промените само на някои файлове могат да бъдат ангажирани в хранилището чрез указване на техните имена: hg commit file1 file2.
Избутване на набор от промени от локално хранилище
Обратно към hg pull команда. Извършва натискане към получаващото хранилище на липсващите набори от промени в сравнение с локалното хранилище.
Добавяне на файлове в хранилището, изтриване на файлове, преименуване
Добавете файлове към хранилището (всъщност те ще бъдат добавени към хранилището, когато изпълните следващата команда hg commit):
Изтриване на файлове от хранилището (историята на промените за посочените файлове в хранилището се запазва, файловете също се изтриват от текущото работно копие):
Преименуването/преместването на файлове, управлявани от mercurial, се извършва със следните команди:
Важно е да запомните, че простото преименуване на файла с помощта на операционната система е нежелателно, т.к. от гледна точка на Mercurial, това би означавало просто изчезването на един от контролираните файлове. С горната команда ние просто уведомяваме системата за контрол на версиите, че името на определен файл е променено, докато цялата съответна хронология на промените също ще бъде правилно свързана с преименувания файл.
Вижте състоянието на текущата работакопия
M - файлът е променен (файлът в работното копие е различен от файла в хранилището)
A - файлът се добавя (при изпълнение на командата hg, ангажиментът действително ще бъде добавен към хранилището)
R - файлът е изтрит (следващият hg ангажимент ще бъде маркиран в хранилището като изтрит за последващи ревизии)
! - файлът е под mercurial контрол, но не е намерен в работното копие (например, изтрит е погрешка от операционната система)
? - файлът присъства в работното копие, но не се управлява от mercurial (за да добавите такъв файл към хранилището, трябва да изпълните hg add filename)
Списъци с игнорирани файлове
Често срещана практика е да се създаде .hgignore файл веднага след създаването на хранилище и да се включи този файл в първия набор от промени ("commit").
Поддържани протоколи
За всички горепосочени случаи, когато е посочено отдалечено хранилище, неговата наличност се подразбира от поне един от транспортните протоколи, поддържани от mercurial. Хранилищата могат да бъдат посочени по следните начини:
local/file/system или file://local/file/system - използва се при работа с хранилище на локалния компютър.
http://user@host:port/path и https://user@host:port/path - използвани за достъп до хранилища, обслужвани от mercurial, работещ в режим на уеб сървър.
ssh://user@host:port/path - използва се за достъп до хранилището чрез ssh протокол. Системата, от която се установява ssh сесията, също трябва да има инсталиран mercurial.
static-http://user@host:port/path - използва се за достъп до хранилища, хоствани на уеб сървър като проста директория. Не изисква присъствиедопълнителен софтуер или настройки. Достъпът в този случай е само за четене.
Mercurial, хостван от NetAngels
Системата за контрол на версиите mercurial е достъпна за всички клиенти на NetAngels, обслужвани на хостинг планове, с изключение на „Основния“ TP. Достъпът до хранилища може да бъде организиран по следните начини:
За ТП "Стандарт" - достъп по ssh протокол. Общественият достъп за четене до хранилището може да бъде осигурен с помощта на протокола static-http. За да направите това, просто трябва да поставите хранилището в дървото на директориите на който и да е от наличните сайтове.
За TP "Profi" или VDS достъпът може да се организира чрез всеки от методите за отдалечена работа с хранилището, поддържано от mercurial.
Работен пример
Да кажем, че започваме работа по проект.
Създайте празно локално хранилище.
Отиваме в създадената директория на myproject репозитория, създаваме списък за изключения .hgignore с маски на името на файла за изключения, маркираме го като управляван от mercurial и правим първия комит - правейки промени в репозитория.
Нека създадем копие на текущото хранилище на хостинга.
Тук "." (точка) сочи към текущата директория, т.е. нашето хранилище. Следва индикацията за отдалеченото хранилище: ssh протокол, потребителско име uXXXX (ssh вход за хостинг клиента на NetAngels), име на хост, директория на хранилището.
Нека създадем няколко файла в работното копие: file1.txt, file2.txt, file3.txt. Нека да маркираме файловете като под mercurial контрол и да се ангажираме действително да ги добавим към хранилището.
За да разпространите промените, направени в локалното хранилище, към отдалечено, трябва да изпълните командата push:
Вече дистанционнохранилището съдържа всички промени, направени локално и може да се използва за клониране или актуализиране на съществуващи копия на хранилища от други разработчици.
Следните ресурси могат да бъдат полезни за допълнително четене:
TortoiseHg - сборка на Mercurial за Windows OS, която включва разширение за Windows Explorer ("Windows Explorer"), което ви позволява да работите с хранилището директно от контекстното меню (екранна снимка).