Git - Как да мигрирам SVN хранилище с история към ново Git хранилище
Прочетох ръководството за Git, често задаваните въпроси, интензивния курс на Git - SVN и т.н. и всички те обясняват това и онова, но никъде не можете да намерите проста инструкция като:
SVN хранилище на: svn://myserver/path/to/svn/repos
Git хранилище на: git://myserver/path/to/git/repos
Не очаквам да е толкова лесно и не очаквам да е една команда. Но очаквам той да не се опитва да обяснява нищо, а само да ви каже какви стъпки да предприемете в този пример.
Git и SVN работят по различен начин. Трябва да знаете Git и ако искате да проследявате промените от SVN нагоре, трябва да знаете git-svn. Страницата на git-svn man има добър пример:
Създайте потребителски файл (т.е. users.txt), за да свържете SVN потребителите към Git:
Можете да използвате този един ред, за да генерирате шаблон от съществуващо SVN хранилище:
SVN ще спре, ако намери липсващ SVN потребител във файла. Но след това можете да актуализирате файла и да продължите там, където сте спрели.
Сега изтеглете SVN данните от хранилището:
Тази команда ще създаде ново Git хранилище в dest_dir-tmp и ще започне да изтегля SVN хранилището. Имайте предвид, че флагът "--stdlayout" означава, че имате общо SVN оформление/, клонове/, тагове/SVN. Ако оформлението ви е различно, проверете опциите --tags , --branches , --trunk (обикновено git svn help ).
Моля, обърнете внимание, че е много често операцията да "зависва/замръзва" след изпълнение на тази команда и е съвсем нормално тя да блокира за дълго време след инициализиране на ново хранилище. В крайна сметка ще видите регистрационни съобщения, които показват, че мигрира.
Същоимайте предвид, че ако пропуснете флага --no-metadata, Git ще добави съответната информация за версията на SVN към съобщението за ангажиране (т.е. git-svn-id: svn://svn.mycompany.com/myrepo/ @ )
Ако потребителското име не бъде намерено, актуализирайте файла users.txt, след което:
Може да се наложи да повторите тази последна команда няколко пъти, ако имате голям проект, докато не бъдат получени всички Subversion транзакции:
Ако искате да запазите други отдалечени клонове във вашето хранилище, ще искате ръчно да създадете локален клон за всеки от тях. (Пропускане на ствол/главен.) Ако не направите това, клоновете няма да бъдат клонирани в последната стъпка.
Етикетите се импортират като разклонения. Трябва да създадете локален клон, да създадете етикет и да изтриете клона, за да ги имате като тагове в Git. Направете го с тага "v1":
Копирайте хранилището на GIT -SVN в чисто хранилище на Git:
Локалните клонове, създадени по-рано от отдалечени клонове, ще бъдат копирани само като отдалечени клонове в новото клонирано хранилище. (Пропускане на ствол/главен.) За всеки клон, който искате да запазите:
И накрая, премахнете дистанционното от вашето чисто Git хранилище, което сочи към вече изтритото временно хранилище:
След това можете да качите данните на Subversion в хранилището на Git:
Ако сте на Mac, можете да получите git-svn от MacPorts, като инсталирате git-core +svn.
Ако вашето subversion хранилище е на същата машина като вашето желано Git хранилище, тогава можете да използвате този синтаксис за началната стъпка, в противен случай всичко е същото:
Използвах svn2git скрипт и работи като чар! https://github.com/nirvdrum/svn2git
Предлагам ви да се запознаете с Git, преди да се опитвате да използвате git-svn през цялото време, т.е.запазете SVN като централизирано репо и използвайте Git локално.
Въпреки това, за проста миграция с цялата история, ето няколко прости стъпки:
Инициализиране на локално репо:
Забележете колко назад искате да започнете да импортирате версии:
(или просто "git svn fetch" за всички кръгове)
Всъщност вземете всичко оттогава:
Можете да проверите резултата от импортирането с Gitk. Не съм сигурен дали това работи на Windows, работи на OSX и Linux:
Ако имате SVN хранилище, клонирано локално, можете да го преместите в централизирано Git repo за по-лесно сътрудничество.
Първо създайте празно отдалечено репо (може би на GitHub?):
След това, по желание, синхронизирайте вашия главен клон, така че операцията по изтегляне автоматично да свързва отдалечения главен към вашия локален главен, когато и двата съдържат нови неща:
След това може да ви е интересно да изпробвате собствения инструмент на git_remote_branch, който ви помага да работите с отдалечени клонове:
Първа обяснителна публикация: Git отдалечени клонове
Има ново решение за безпроблемна миграция от Subversion към Git (или за едновременна употреба): SubGit (http://subgit.com/).
Аз самият работя по този проект. Ние използваме SubGit в нашите хранилища - някои от съотборниците ми използват Git и някои Subversion и досега работи много добре.
За да мигрирате от Subversion към Git с помощта на SubGit, трябва да изпълните:
След това ще имате Git repo в svn_repos/.git и можете да го клонирате или просто да продължите да използвате Subversion и това ново Git repo заедно: SubGit ще гарантира, че и двете са винаги синхронизирани.
Ако твоятТъй като едно хранилище на Subversion съдържа множество проекти, множество Git хранилища ще бъдат създадени в директорията svn_repos/git. За да настроите излъчване преди стартиране, изпълнете следните стъпки:
Със SubGit можете да превключите към чист Git (не git-svn) и да започнете да го използвате, като същевременно запазите Subversion толкова дълго, колкото ви е необходим (например за вашите вече конфигурирани инструменти за компилация).
Надявам се това да помогне!
Вижте официалната git-svn страница с ръководство. По-специално вижте под „Основни примери“:
Проследяване и принос към цял проект, управляван от Subversion (в комплект с ствол, тагове и клонове):
SubGit (срещу син екран на смъртта)
+ За актуализиране от SVN, Git хранилището, създадено от първата команда.
Използвах начина за незабавно превключване към Git за огромно хранилище. Разбира се, имате нужда от подготовка. Но изобщо не е нужно да спирате процеса на разработка.
Моето решение изглежда така:
- Мигрирайте SVN към Git хранилище
- Актуализирайте Git хранилището, преди да преместите командата в.
Миграцията отнема много време за голямо SVN хранилище. Но актуализирането на завършена миграция е само за секунди.
Разбира се, че използвам SubGit, мамо. git -svn ми дава синия екран на смъртта. Просто постоянно. И git -svn ме отегчи с git "името на файл твърде дълго" фатална грешка.
СТЪПКА
2. Подгответе командите за прехвърляне и актуализиране.
Да кажем, че правим това за Windows (тривиално е за Linux порт). В директорията SubGitbin (subgit-2.X.X\bin) създайте два .bat файла.
Прехвърляне на съдържание на файл/команда:
Командата "старт" тук не е задължителна (Windows). Това ще ви позволи да видите грешки при стартиране и да излезетечерупката се отваря, след като SubGit завърши.
(Ако искате да мигрирате тагове като разклонения или вашият SVN има множество разклонения/папки с етикети, можете да използвате по-подробния подход Subgit)
Съвет 2. Миграцията може да бъде прекъсната (Ctrl + C) и възстановена чрез изпълнение на следната команда/файл за актуализиране. Не препоръчвам да правите това за големи хранилища. Получих „Изчерпателно Java + Windows изключение“.
Съвет 3. По-добре е да създадете копие на вашето хранилище без резултати.
Съдържанието на файла/командата за актуализиране:
Можете да го стартирате колкото пъти искате последната команда да ангажира вашето Git хранилище.
Предупреждение! Не докосвайте голото си хранилище (например, създавайки разклонения). Ще получите следната фатална грешка:
Фатална грешка: Не е синхронизирано и не може да се синхронизира. Превеждане на версии на Subversion в Git ангажименти.
3. Изпълнете първата команда/файл. Голямото хранилище ще изисква време за изчакване. 30 часа за моето скромно съхранение.
Всичко. Можете да актуализирате Git хранилището от SVN по всяко време, колкото и много пъти, като изпълните втория файл/команда. И преди да превключите екипа си за разработка на Git. Това ще отнеме няколко секунди.
Има още една полезна задача.
Избутване на локално Git хранилище към отдалечено Git хранилище
Вашият случай ли е? Да продължим.
- Подгответе първоначалното насочване на вашето огромно локално Git хранилище към отдалеченото хранилище
По подразбиране вашият Git не може да изпраща големи парчета. фатален: Отдалеченият край неочаквано затвори
Бягайте за това:
524288000 - 500 MB 1073741824 - 1 GB и др.
Коригиране на проблеми с локален сертификат. Ако вашият git сървър използва повреден сертификат.
Имам деактивирани сертификати.
Освен това вашият Git сървър може да има ограничения за броя на заявките, които трябва да бъдат коригирани.
Стартирайте с локален Git:
(git push origin '*: *' за по-стари версии на Git)
Ако получите следното:грешка: Git не може да се появи: Няма такъв файл или директория. За мен пълното възстановяване на хранилището ми решава тази грешка (30 часа). Можете да опитате следните команди
Или опитайте да преинсталирате Git (безполезен за мен ). Или можете да създадете разклонения от всичките си тагове и да ги натиснете. Или, или, или.
репохирург
За сложни случаи хранилището на Eric S. Raymond е инструментът на избор. В допълнение към SVN, той поддържа много други системи за контрол на версиите чрез формата за бързо експортиране, както и CVS. Авторът съобщава за успешни конверсии на древни хранилища като Emacs и FreeBSD.
Инструментът изглежда се стреми към почти перфектно преобразуване (напр. преобразуване на SVN svn:ignore свойства в .gitignore файлове) дори за сложни оформления на хранилище с дълга история. В много случаи други инструменти може да са по-лесни за използване.
Преди да се задълбочите в документацията на командния ред на reposurgeon, не забравяйте да прочетете отличното ръководство за мигриране на DVCS, което ще ви преведе през процеса на преобразуване стъпка по стъпка.
Това ръководство на сайта atlassian е едно от най-добрите, които съм намирал:
Този инструмент - https://bitbucket.org/atlassian/svn-migration-scripts - също е много полезен за генериране на вашия author.txt между другото.
Донякъде разширен отговор, използващ само git, SVN и bash. Включвавключва стъпки за SVN хранилища, които не използват нормално оформление с оформление на ствол/клонове/етикети (SVN не прави абсолютно нищо, за да наложи такова оформление).
Първо използвайте този bash скрипт, за да сканирате вашето SVN репо за различни хора, които са допринесли и да създадете шаблон за файла за картографиране:
Използвайте това, за да създадете файл за автори, където съпоставяте svn потребителски имена с потребителски имена и имейли, дадени от вашите разработчици, като използвате свойствата на git config user.name и user.email (имайте предвид, че за услуга като GitHub е достатъчно да имате съответния имейл).
След това git svn клонира svn хранилището в git хранилището, казвайки му да картографира:
git svn clone --authors-file=authors --stdlayout svn://example.org/Folder/projectroot
Това може да отнеме много време, тъй като git svn ще проверява всяка ревизия поотделно за всеки съществуващ етикет или клон. (обърнете внимание, че таговете в SVN са наистина разклонения, така че те завършват като такива в Git). Можете да ускорите това, като премахнете стари етикети и разклонения в SVN, които не ви трябват.
Правенето на това на сървър в същата мрежа или на същия сървър също може наистина да ускори това. Освен това, ако по някаква причина този процес бъде прекъснат, можете да го възобновите с
git svn rebase --continue
В много случаи вие сте тук. Но ако вашето SVN репо има нетрадиционно оформление, където просто имате директория в SVN, която искате да поставите в git клон, можете да предприемете няколко допълнителни стъпки.
Можете също да направите това с помощта на git. За git svn clone просто използвайте директорията, която искатепоставете в git клон.
Имайте предвид, че това изисква git 1.7 или по-нова версия.
Трябва да инсталирате
1. Вземете списък на всички комититори на Subversion
От корена на вашето локално плащане на Subversion изпълнете следната команда:
Това ще вземе всички съобщения в журнала, ще премахне потребителските имена, ще елиминира всички дублирани потребителски имена, ще сортира потребителските имена и ще ги постави във файла "authors-transform.txt". Сега редактирайте всеки ред във файла. Например конвертирайте:
2. Клонирайте хранилището на Subversion с git -svn
Това ще бъде стандартната трансформация на git-svn (с помощта на файла authors-transform.txt, създаден в стъпка 1) и поставете Git хранилището в папката "
/temp" във вашата начална директория.
3. svn transform: игнорирайте свойствата преди .gitignore
Ако вашият svn repo използва svn:ignore свойства, можете лесно да го конвертирате в .gitignore файл, като използвате:
4. Избутване на хранилище към голо Git хранилище
Първо, създайте голо хранилище и го разклонете обратно по подразбиране svns "trunk" .
След това преместете временното хранилище в новото отворено хранилище.
Сега можете безопасно да премахнете хранилището
5. Преименувайте клон "trunk" на "master"
Вашият основен клон за разработка ще се нарича "trunk", което съответства на името, което беше в Subversion. Искате да го преименувате на стандартен клон на Git с:
6. Почистване на клонове и етикети
git -svn прави всички тагове на Subversions в много кратки разклонения в Git под формата "тагове/име". Ще искате да конвертирате всички тези клонове в действителни Git тагове, като използвате:
Тази стъпка ще отнеме малковход.:-) Но не се притеснявайте; вашата unix обвивка ще осигури > вторична подкана за изключително дългата команда, която започва с Git за всяка реф.