Първи миграции от CVS към Git
Миналия Май имах доброто намерение да започна постепенно да мигрирам старите ми CVS хранилища към Git, но успях само да започна процеса тези почивни дни. Преди да се гмурна по-дълбоко реших да мигрирам някои по-малки хранилища с линейна история, за да мога да се упражня, проверя и овладея процеса. В резултат някои малки проекти вече се приземиха в моя GitHub профил (виж guthub.com/gdsotirov). Четох доста за миграция от CVS и SVN към Mercurial и Git във връзка с вътрешен проект във фирмата за която работя. Също така вече съм експериментирал мигриране от CVS към SVN в миналото и от CVS към Hg/Git наскоро, така че се смятах за подготвен, но все пак има някои неща, които трябва да се имат в предвид при правенето на такава миграция.
* Добавено това
* Променено онова
Трябваше да променя тези коментари в CVS, преди миграцията, защото те просто не изглеждат добре в TortoiseGit и GitHub. Също така уеднаквих някои подобни коментари на файлове с качвания в разстояние на няколко минути, така че миграцията да ги събере в една ревизия. В зависимост от това дали имате конвенция за формата на съобщенията за журнала на ревизиите в CVS може да ви се наложи да правите други нагаждания. Най-лесния начин в този случай е може би промяна директно в файла с версиите с perl, sed, awk, и т.н. като разбира се действате предпазливо, за да не съсипете историята си (т.е. подобни операции не трябва да се изпълняват на "живо" хранилище в продукция).
Автори. Трябва да можете да идентифицирате всичките си автори, защото в CVS хранилищата те нормално са UNIX имена за вход и потребителите може вече да не съществуват в системата. Виждал съм дори случаи в които едно и също потребителско име е използвано от различни разработчици имащи същите собствени и фамилни имена. Трудно е да се намерят и оправят такива ревизии освен ако не си наясно със стажа на разработчиците в компанията, но какво ако времето им в компанията се засича?
За щастие, аз нямам този проблем с личните ми хранилища, но все пак трябва да пренапиша потребителското си име като пълно име и адрес за електронна поща (виж още за това в глава Step One: The Author Map в статията DVCS migration HOWTO на Ерик Реймънд). Много важно е да се пренапишат авторите, защото иначе версиите няма да бъдат правилно идентифицирани в GitHub (виж Contributions that are counted). Ако трябва да оправяте потребителски имена за предпочитане е да го направите в CVS хранилището преди миграцията. А най-лесния начин да свържете потребителски имена с автори е да пренапишете превърнатото Git хранилище за което пиша по-надолу.
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.
За сега не съм имал проблеми с миграцията - историята се пресъздаде правилно в Git. Обаче, с много етикети и клонове по различни файлове нещата могат да станат доста объркани както открих покрай вътрешния проект в службата. След миграцията проверявам резултата и ако е нужно оправям още съобщения за журнала на ревизиите. После, просто пренаписвам авторите със скрипта даден в Changing author info и накрая внасям хранилището в GitHub (напр. ползвам git daemon --verbose --export-all --base-path="/path/to/repo" за подаване на превърнатото хранилище). След внасянето в GitHub трябва да добавя LICENSE и README.md файлове, нот това е доста тривиално през уеб интерфейса.
Подготовка на хранилището
Съобщения за журнала на ревизиите. Може да имате конвенция за писане на съобщения за журнала на ревизиите в 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 файлове, нот това е доста тривиално през уеб интерфейса.
И това е всичко. Имам още хранилища да мигрирам и наистина се надявам да мога да приключа тази задача до края на годината, но всичко ще зависи от това колко бързо ще мога да подготвя хранилищата, защото след това е работа на инструментите.
