Миграциите към Git и GitHub продължават

Миналата година започнах миграция от CVS към Git и GitHub (виж Първи миграции от CVS към Git), което е нещо което исках да започна още през 2018-та (виж Миграция към Git и GitHub), а планирах дори от по-отдавна. Е, оказа се трудна задача, защото все още мигрирам, тъй като много от CVS хранилищата ми изискваха поправки, така че историята да може да бъде правилно прехвърлена в Git. По време на миграциите бях изненадан колко небрежен съм бил към кода си, защото открих непродадени промени от преди чак 10 години, повредени файлове с ревизии и различни несъответствия в историята. След като мигрирах някои проекти веднага започнах да работя по обновявания и поправки, така че вече продължавам работата си в Git. Също така пуснах непрекъсната интеграция за някои проекти използвайки Travis CI и GitHub Actions.

В момента мигрирам Slackware скриптовете си за изграждане на пакети, които са колекция от над 300 шел скрипта и свързаните с тях файлове организирани като отделни хранилища в отделни директории, но под един корен. В CVS това беше напълно в реда на нещата, но не произвежда добра история в Git, защото етикетите за версии или клонове (напр. FFmpeg-3_4_7 или MySQL-5_5) са специфични само за определен скрипт и използвани само от файловете в съответната му директория. Затова реших да ги мигрирам отделно и да ги обединя в друго хранилище с под модули. Има доста проблеми и с тази миграция.

Това са някои от проблемите:

• етикети или клонове с подобни имена (напр. TEST-123 и TEST_123). Тези са лесни за оправяне - просто трия грешния етикет/клон;
• неправилно поставени етикети или клонове. Тъй като в CVS поставях етикети и започвах клонове както е нужно някои етикети и клонове бяха поставени на различни файлове в различно време, което в Git историята се отразява като подавания със съобщение "This commit was manufactured by cvs2git to create tag 'TEST-123'" или "This commit was manufactured by cvs2git to create branch 'TEST-123'" с файлове които са добавени, премахнати или променени, за да се нагласи историята за съответния етикет или клон. Оправям такива проблеми с пренареждане на проблемните подавания, което е лесно само със смяна на датата във файла с ревизии в хранилището, но отнема време да се прегледа и разбере причината;
• неизползвани файлове, които не са изтрити в историята. Това също предизвиква подавания със съобщения като споменатите в предишната точка. Тези проблеми оправям с изтриване на неизползваните файлове с минала дата, така че те да не се взимат в предвид от следващи подавания;
• файлове принадлежащи на клон, но подадени в ствола вместо това. Подобно на предходното. В някои случаи, има файлове, които трябва да съществуват само по някакъв клон (напр. като кръпки за поправка на проблеми с конкретна версия на софтуера), но са били подадени в ствола. Тъй като в CVS няма голяма разлика между етикети и клонове е било достатъчно да има етикет на промените, за да се изваждат правилно. Премествам такива от ствола в клон, което означава изтриване на ревизиите от ствола и преместването им върху клона;
• правописни грешки. Тъй като най-вече подавах към CVS от команден ред и не използвах проверка на правописа имам много съобщения към подавания с правописни грешки, които дразнят очите ми. Поправям ги след първоначална миграция към Git, за да мога да проверя всички съобщения наведнъж.

Два инструмента се оказа от голяма помощ след миграция - licensee и github-linguist. Използвам първия, за да проверя дали лиценза се открива правилно. Имах някои проблеми (виж бъгове 361 и 392) с някои от проектите ми, затова сега проверявам преди да бутна към GitHub. Втория е полезен за фина настройка на откриването на езиците (напр. искам да виждам просто SQL, а не PLSQL, PLpgSQL, SQLPL или TSQL, които лингвист би открил, въпреки че всичките ми публикувани SQL изходни кодове са за MySQL. И за мен SQL е код, не данни).

Както и да е публикувам това, за да отбележа, че миграциите ми към Git продължават. Постигнах голям напредък миналата година мигрирайки 28 хранилища. А тази година досега мигрирах още 114. Така надявам се до края на годината ще бъда свободен от ползване на CVS (или поне само по изключение). Първоначално планувах да мигрирам всичко, но вече смятам да пропусна някои проекти и примери с по-ниска стойност, които ако е нужно, мога да мигрирам по-късно.

Първи миграции от CVS към Git

Миналия Май имах доброто намерение да започна постепенно да мигрирам старите ми CVS хранилища към Git, но успях само да започна процеса тези почивни дни. Преди да се гмурна по-дълбоко реших да мигрирам някои по-малки хранилища с линейна история, за да мога да се упражня, проверя и овладея процеса. В резултат някои малки проекти вече се приземиха в моя GitHub профил (виж guthub.com/gdsotirov). Четох доста за миграция от CVS и SVN към Mercurial и Git във връзка с вътрешен проект във фирмата за която работя. Също така вече съм експериментирал мигриране от CVS към SVN в миналото и от CVS към Hg/Git наскоро, така че се смятах за подготвен, но все пак има някои неща, които трябва да се имат в предвид при правенето на такава миграция.

Подготовка на хранилището

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

* Добавено това
* Променено онова

Трябваше да променя тези коментари в CVS, преди миграцията, защото те просто не изглеждат добре в TortoiseGit и GitHub. Също така уеднаквих някои подобни коментари на файлове с качвания в разстояние на няколко минути, така че миграцията да ги събере в една ревизия. В зависимост от това дали имате конвенция за формата на съобщенията за журнала на ревизиите в CVS може да ви се наложи да правите други нагаждания. Най-лесния начин в този случай е може би промяна директно в файла с версиите с perl, sed, awk, и т.н. като разбира се действате предпазливо, за да не съсипете историята си (т.е. подобни операции не трябва да се изпълняват на "живо" хранилище в продукция).

Автори. Трябва да можете да идентифицирате всичките си автори, защото в CVS хранилищата те нормално са UNIX имена за вход и потребителите може вече да не съществуват в системата. Виждал съм дори случаи в които едно и също потребителско име е използвано от различни разработчици имащи същите собствени и фамилни имена. Трудно е да се намерят и оправят такива ревизии освен ако не си наясно със стажа на разработчиците в компанията, но какво ако времето им в компанията се засича?
За щастие, аз нямам този проблем с личните ми хранилища, но все пак трябва да пренапиша потребителското си име като пълно име и адрес за електронна поща (виж още за това в глава Step One: The Author Map в статията DVCS migration HOWTO на Ерик Реймънд). Много важно е да се пренапишат авторите, защото иначе версиите няма да бъдат правилно идентифицирани в GitHub (виж Contributions that are counted). Ако трябва да оправяте потребителски имена за предпочитане е да го направите в CVS хранилището преди миграцията. А най-лесния начин да свържете потребителски имена с автори е да пренапишете превърнатото Git хранилище за което пиша по-надолу.

Инструменти

В такъв процес едно от най-важните неща е да се изберат правилните инструменти, защото просто не можете да минете без тях. Миналата година в работата оценявахме различни възможности и в крайна сметка се спряхме на cvs2git, който е част от cvs2svn проекта. Командата е писана на Python и поддържа различни възможности. За мен е важно да направя най-добрата възможна миграция, така че трябваше да направя следните промени в примерния файл с настройки:

KeywordHandlingPropertySetter('expanded'),

from cvs2svn_lib.keyword_expander import _KeywordExpander
# Ensure dates are expanded as YYYY/MM/DD as in CVS 1.11
_KeywordExpander.use_old_date_format()

Първата линия осигурява разширяването на CVS ключовите думи (напр. $Id$, $Date$, и т.н.) в текстови файлове (виж тема cvs2svn changes 'date' string in source codes). Следващите три линии осигуряват това датите в ключови думи да се разширяват като в CVS 1.11 или в YYYY/DD/MM формат, вместо във формата по подразбиране YYYY-MM-DD като в CVS 1.12 и SVN.

Миграция

Начина за обръщане на CVS хранилище в Git е описан в документацията на cvs2git (виж глава Usage), така че просто я прочетете. Аз си написах шел скрипт, който да изпълнява различните стъпки описани там. Първоначално използвах cvs2git само с настройки на командния ред, но заради изискванията ми за разширяване на ключови думи (виж отгоре), трябваше да подобря скрипта да създава файл с настройки и да го ползвам вместо това. Така запазих начина на извикване на скрипт само с подаване на път към CVS хранилище.

За сега не съм имал проблеми с миграцията - историята се пресъздаде правилно в Git. Обаче, с много етикети и клонове по различни файлове нещата могат да станат доста объркани както открих покрай вътрешния проект в службата. След миграцията проверявам резултата и ако е нужно оправям още съобщения за журнала на ревизиите. После, просто пренаписвам авторите със скрипта даден в Changing author info и накрая внасям хранилището в GitHub (напр. ползвам git daemon --verbose --export-all --base-path="/path/to/repo" за подаване на превърнатото хранилище). След внасянето в GitHub трябва да добавя LICENSE и README.md файлове, нот това е доста тривиално през уеб интерфейса.

И това е всичко. Имам още хранилища да мигрирам и наистина се надявам да мога да приключа тази задача до края на годината, но всичко ще зависи от това колко бързо ще мога да подготвя хранилищата, защото след това е работа на инструментите.

Миграция към Git и GitHub

Преди няколко години реших да мигрирам всичките си лични проекти към разпределена система за контрол на версиите (РСКВ), но така и не намерих времето за това. В днешно време Git е де факто стандарт за контрол на версиите затова реших да мигрирам към Git и кача всичките си проекти в GitHub. Така че тази година постепенно ще мигрирам проектите си, започвайки с най-малко активните. Повечето от тях са все още на CVS, което прави миграцията по-сложна като се има в предвид, че CVS и Git са доста различни в много отношения, но също така защото за мен е важно да запазя историята на промените си (т.е. не искам просто да копирам кода и инициализирам ново Git хранилище вътре). Пожелайте ми успех и ми стискайте палци ;-)