7.2 Git и други системи - Миграция към Git

Ако сте прочели секцията за използването на git svn, може да сте ползвали тези инструкции за да направите git svn clone към хранилище, след това да сте спрели да използвате Subversion сървъра, да сте публикували в нов Git сървър и да ползвате него занапред. Ако искате историята, може да направите това толкова бързо колкото може да теглите от Subversion сървъра (което може да отнеме доста време).

Обаче, импортът не е перфектен и понеже може да отнеме време, няма да е лошо да го направите правилно. Първият проблем е с информацията за автора. В Subversion, всеки къмитващ автор има акаунт на сървъра, който се записва в къмит информацията. Примерите в предишната секция показваха schacon в някои позиции, като наприме blame изхода и git svn log. Ако искате да свържете тази информация с информацията за авторите в Git, ще ви трябва някакъв мапинг между Subversion потребителските акаунти и Git авторите. Създайте файл users.txt, който прави мапинга така:

За да получите списък с имената на авторите, които SVN използва:

Това генерира лог изхода в XML формат, след това филтрира само редовете с author данни, премахва повторенията и изчиства XML таговете. Очевидно това ще работи при налични grep, sort, и perl. След това, пренасочете този изход във файла users.txt, така че да добавите еквивалентните Git потребителски данни във всеки ред.

Може да подадете този файл на командата git svn за да я подпомогнете в по-акуратното мапване на данните за авторите. Можете също да укажете на git svn да не включва метаданните, които Subversion нормално импортира с флага --no-metadata към командите clone или init. Метаданните включват git-svn-id вграден във всяко къмит съобщение, което Git ще генерира по време на импорта. Това може да задръсти вашия Git лог и да го направи по-неясен.

Така командата import ще изглежда по следния начин:

Сега ще имате по-красив Subversion импорт в директорията my_project. Вместо къмити изглеждащи така:

те ще се показват като:

Сега не само полето Author изглежда по-добре, но и git-svn-id информацията няма да се появява.

Бихте могли да направите и допълнително почистване след импорта. Добре би било да махнете странните референции, които git svn настройва. Първо ще преместите таговете, така че да бъдат реални тагове вместо странни отдалечени референции и след това ще преместите останалите клонове, така че да станат локални.

За да превърнете таговете в реални Git тагове, изпълнете:

Това ще вземе референциите представляващи отдалечени клонове и започващи с refs/remotes/tags/ и ще ги конвертира в реални олекотени тагове в Git.

След това, преместваме останалите референции от refs/remotes като локални клонове:

Може да се случи да видите някои допълнителни клонове със суфикс @xxx (където xxx е число), докато в Subversion виждате само един клон. Това в действителност е Subversion функция наречена “peg-revisions”, за която Git просто няма синтактичен аналог. По тази причина git svn просто добавя svn version номера към името на клона точно по същия начин, по който бихте го написали в svn за да адресирате въпросния peg-revision в този клон. Ако тези peg-revisions не ви интересуват, може просто да ги премахнете:

Сега всички стари клонове са реални Git клонове и всички стари тагове са реални Git такива.

Има още едно последно нещо за коригиране. За съжаление, git svn създава допълнителен клон с име trunk, който съответства на клона по подразбиране на Subversion, но указателят trunk сочи към същото място, към което и master. Понеже master е нещото, с което сме свикнали с Git, ето как да премахнете допълнителния клон:

Последно, добавяме нашия нов Git сървър като remote и публикуваме в него:

Понеже искаме всичките ни клонове и тагове да се публикуват, можем да изпълним:

Сега всичките клонове и тагове ще са в новия ни Git сървър в резултат на един подреден и изчистен импорт.

Mercurial и Git имат подобни модели за представяне на версиите и понеже Git е малко по-гъвкав, конвертирането на хранилище от Mercurial към Git е сравнително лесно чрез инструмента "hg-fast-export", който можете да свалите от:

Първата стъпка е да се сдобием с пълно копие на хранилището на Mercurial, което ще конвертираме:

Следващата е да създадем author mapping файл. Mercurial е по-малко рестриктивен от Git по отношение на това какво може да се слага в author полето на changeset-ите, така че това е удобен момент за почистване. Създаването на списъка отнема една команда в bash шела:

Това ще отнеме няколко секунди в зависимост от дължината на историята на проекта, след което файлът /tmp/authors ще изглежда по подобен начин:

В този конкретен пример, един и същи човек (Bob) е създал changeset-и под четири различни имена, едно от които изглежда коректно и друго, което ще е изцяло невалидно за един Git къмит. Hg-fast-export ни позволява да коригираме това превръщайки всеки ред в правило: "<input>"="<output>", мапвайки <input> към <output>. В стринговете <input> и <output>, са позволени всички escape последователности, които се поддържат от string_escape енкодинга на python. Ако author mapping файлът не съдържа съответен <input>, този автор ще се изпрати към Git непроменен. Ако всички потребителски имена изглеждат добре, то въобще няма да се нуждаем от такъв файл. В този пример искаме файлът ни да изглежда така:

Същият вид мапинг файлове може да се използва за преименуване на клонове и тагове, когато дадено Mercurial име не е позволено за Git.

След това е време да създадем новото ни Git хранилище и да пуснем експортиращия скрипт:

Флагът -r инструктира hg-fast-export къде да намери Mercurial хранилището, което ще се конвертира, а -A указва къде е author-mapping файла (съответно за файловете за клонове и тагове се използват флаговете -B и -T). Скриптът парсва Mercurial changeset-ите и ги конвертира в скрипт за целите на "fast-import" функцията на Git (ще я разгледаме малко по-късно). Това отнема малко време (но за сметка на това е много по-бързо, в сравнение с времето необходимо, ако трябваше да се прави по мрежата) и изходът е доста подробен:

Това е почти всичко. Всички Mercurial тагове са конвертирани в Git тагове и Mercurial клоновете и bookmarks обектите са превърнати в съответните Git клонове. Сега сте готови да публикувате хранилището в сървъра:

Bazaar е DVCS инструмент подобен на Git и е сравнително лесно да конвертирате Bazaar хранилище в Git такова. За целта ви трябва плъгина bzr-fastimport.

Следващата система, за която ще разгледаме процеса по импортиране на данни, е Perforce. Както видяхме по-рано, Git и Perforce могат да комуникират по два начина: посредством git-p4 и Perforce Git Fusion.

Ако системата ви не е сред дотук разгледаните, може да потърсите импортиращ инструмент в Интернет — качествени такива са налични за CVS, Clear Case, Visual Source Safe, дори за директория от архиви. Ако никой от тях не работи в конкретния случай или се нуждаете от по-специфичен процес на импортиране, тогава може да използвате git fast-import. Тази команда чете прости инструкции от стандартния вход за да записва специфични Git данни. Много по-лесно е да създавате Git обекти по този начин, вместо да използвате raw Git командите или да се опитвате да записвате raw обекти (вижте Git на ниско ниво за повече информация). По този начин можете да напишете собствен импортиращ скрипт, който чете необходимата информация от системата, от която импортирате и печата последоветелно инструкции към стандартния изход. Можете да пуснете програмата и да пренасочите изхода ѝ към git fast-import.

За демонстрация, ще напишем прост импортиращ инструмент. Да приемем, че работите в директория current, редовно архивирате проекта си в отделни директории именувани back_YYYY_MM_DD според датата, и в един момент решавате да импортирате всичко това в Git хранилище. Структурата на директориите изглежда така:

За да импортираме Git директория, трябва да разгледаме как Git съхранява данните си. Както може би помните, Git грубо казано е свързан списък от къмит обекти, които сочат към snapshot-и от съдържание. Всичко, което трябва да укажете на fast-import е какво са snapshot-ите със съдържание, какви къмит данни сочат към тях и реда, по който идват. Стратегията е да минаваме по snapshot-ите един след друг и да създаваме къмити със съдържанието на всяка директория свързвайки всеки къмит с предишния.

Както го направихме в Примерна Git-Enforced политика, ще пишем скрипта си на Ruby. Бихте могли да използвате езика, с който вие се чувствате комфортно — просто трябва да печатате съответната информация на stdout. Освен това, ако сте под Windows, трябва да внимавате да не вмъквате carriage returns символи в края на редовете — git fast-import е чувствителен за това и очаква само line feeds (LF) а не carriage return line feeds (CRLF), което нормално се случва под Windows.

За начало, влизаме в съответната директория и идентифицираме всяка поддиректория, която ще бъде snapshot, който да импортираме. След това, печатаме командите, необходими за експорта. Основният цикъл изглежда по такъв начин:

Изпълняваме print_export от всяка директория, което взема манифеста и маркировката на предишния snapshot и връща манифеста и маркировката на текущия. По този начин можем да ги свържем коректно. Маркировката (“Mark”) във fast-import е термин за идентификатор, който давате на къмит. Когато създавате къмити, вие давате на всеки от тях маркировка, която може да се ползва за свързване към него от други къмити. Така първото нещо, което трябва да направи метода print_export, е да генерира маркировка от името на директорията:

Ще направим това създавайки масив от директориите и ще използваме индексите като маркировки, защото те трябва да са цели числа. Методът изглежда така:

Сега имаме целочислено представяне на къмита и ни трябва дата за неговите метаданни. Понеже казахме, че датата е отразена в името на директорията, ще я извлечем оттам. Следващият ред от print_export файла е:

където convert_dir_to_date се дефинира като:

Това връща целочислена стойност за датата на всяка директория. Последната необходима част за метаданните е информация за автора, която ще хардкоднем в глобална променлива:

Сега сме готови да започнем печатането на къмит данните за нашия importer. Началните данни твърдят, че създаваме къмит обект с данни за това в какъв клон е той, следвани от генерираната маркировка, информацията за автора и къмит съобщението и след това — предишния къмит, ако има такъв. Кодът изглежда така:

Тайм зоната е твърдо зададена на (-0700) за улеснение. Ако импортираме от друга система, трябва да укажем тайм зоната като отместване. Къмит съобщението трябва да се представи в специален формат:

Форматът представлява последователност от думата data, размерът на данните за прочитане, нов ред, и накрая, самите данни. Тук ще използваме helper метод наречен export_data, защото по-късно се нуждаем от същия формат за указване на съдържанието на файловете.

Остана да укажем файловото съдържание на всеки snapshot. Това е лесно, защото имаме всеки един в директория — можете да отпечатате командата deleteall последвана от съдържанието на всеки файл в директорията. Git след това ще запише съответно всеки snapshot:

Заб.: Понеже много системи представят версиите си като промени между два къмита, fast-import може също така да приема команди с всеки къмит, които да указват кои файлове са били добавени, премахнати или модифицирани и какво е новото съдържание. Можете да изчислите разликите между snapshot-ите и да подадете само тези данни, но това е по-сложно и може да оставите на Git да го свърши като просто подадете всички данни. Ако все пак искате това да е ваша работа, погледнете документацията на fast-import за повече подробности как точно да я извършите.

Форматът за подаване на ново файлово съдържание или за модифицирано такова е както следва:

Тук, 644 е режимът за файла (ако имате изпълними такива, трябва да ги установите и да ги подадете като 755), а inline казва, че ще предоставите съдържанието веднага след този ред. Методът inline_data изглежда така:

Използваме метода export_data дефиниран по-рано, понеже форматът е като за данните на къмит съобщенията.

Последното нещо, което трябва да сторим е да върнем текущата маркировка, така че тя да бъде изпратена към следващата итерация:

Това е. Ето целия скрипт:

Ако го изпълним, получаваме съдържание подобно на това:

За да стартираме importer-а, пренасочваме изхода през git fast-import докато сме в Git директорията, в която искаме да импортираме. Може да създадем нова директория, да изпълним git init в нея за начална точка и да пуснем скрипта:

Както се вижда, при успешен завършек получавате подробна статистика за извършените дейности. В този случай сме импортирали 13 обекта за 4 къмита в 1 клон. Сега може да изпълним git log за да видим новополучената история:

Получавате чисто ново Git хранилище. Важно е да отбележим, че нищо не е извлечено на този етап — отначало работната директория е празна. За да си получим файловете, трябва да върнем клона си там където е master в момента:

Можете да правите още много неща с fast-import инструмента — да обработвате различни режими, двоични данни, множество клонове и сливане, тагове, индикатори за прогрес и т.н. Има много примери за по-сложни сценарии в директорията contrib/fast-import в сорс кода на Git.