Мигриране на git svn ангажименти с преместени и преместени ангажименти

Опитваме се да мигрираме основното си хранилище на източника от svn към git Първият ми опит беше просто да направя git svn клонинг. След като клонирането беше направено, открих, че първият комит е през ноември 2012 г. Знам със сигурност, че кодът е на няколко години. Разглеждайки svn repo, изглежда, че първият комит към главната директория е извършен през ноември 2012 г., докато няколко файла в репото са ангажирани години преди това. И така, как файловете в директория могат да бъдат ангажирани преди родителската директория..

Разпитах наоколо, тъй като съм нов в компанията и никой не знае със сигурност, но това репо претърпя няколко svn relocate и svn преместване по необичаен начин, например те се развиха в клон, след което преместиха този клон като директория в ствола или се развива в клон, след което преименува този клон на ствол и т.н.

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

svn up -r 599 http://myrepo/trunk

и получи грешката:

svn: E195012: Unable to find repository location for 'http://myrepo/trunk' in revision 559

Тази грешка е възпроизводима за всички ангажименти преди ноември 2012 г., т.е. тези, които могат да бъдат заявени с помощта на svn log, но не могат да бъдат извлечени

Добрата новина е, че мога да направя нещо като:

svn diff -r 599 http://myrepo/trunk

Следващият ми подход е да прегледам всички ангажименти с помощта на svn diff, да създам пачове и да ги приложа към git, като използвам оригиналния автор, дата и т.н.

Някакви по-добри идеи как да извлечете такива повредени ангажименти?

Нямам физически достъп до репото и не мога да използвам svnadmin

Редактиране 1:

Оказа се, че не правя заявка в главната директория, а едно ниво надолу в дървото, затова получавах такива грешки. Както и да е, направих svnrdump и успях да изхвърля цялото хранилище (> 32K ангажименти), също така репото съдържаше повредени комити, които трябваше да пропусна.

Освен това е внесен на местно ниво. Това ми помогна да разбера по-добре какво се е случило

По принцип репото имаше много хаотична структура, нещо подобно

svn 
   |_Project1 
         |_subproject1 
               |_branches 
                      |_branch1 
                      |_branch2 
               |_trunk 
               |_tags 
                      |_tagv1 
   |_Non-JavaProject 
         |_subproject 
   |_Project2 
          |_AnotherSubproject 
               |_SubSubproject 
          |_Subproject2 
               |_branches 
               |_tags 
          |_Subproject3 
               |_trunk 
          |_Subproject4 
               |_Subsubproject 
                       |_branches 
                       |_tags 
                       |_trunk

Това, което се случи след това, е, че използвайки смес от svn mv и copy, структурата беше малко усъвършенствана

svn |_mainProject |_trunk |_branches |_tags

Така че сега имаме пътища като

mainProject/trunk/_Project1
mainProject/trunk/_Project1/subproject1
mainProject/trunk/Project2/AnotherSubproject/SubSubproject

и същото важи за клонове/тагове

С други думи, трябва да дефинирам в .git/config във fetch и други заглавки метод, така че различните директории от mainProject да следват различни (множество) стари пътища

Възможно ли е това?


git git-svn svn
person Moataz Elmasry    schedule 29.04.2014    source източник
comment
Звучи сякаш се опитвате да диагностицирате това с една ръка, вързана зад гърба. Ако не можете да получите достъп до действителното хранилище на Subversion, вижте дали можете да получите копие от него, за да работите с него локално. Най-малкото копие на изхода svnadmin dump вероятно ще помогне. Но ако изходното хранилище е повредено по някакъв начин, тогава дъмпът също ще бъде повреден.   -  person Greg Hewgill    schedule 30.04.2014
comment
svn up http://myrepo/trunk@599 работи ли за вас? Вижте durak.org/sean /pubs/software/ за подробности относно ревизиите на PEG, което може да помогне.   -  person Matthew Strawbridge    schedule 30.04.2014
comment
Не вярвам, че svn up приема URL. Можете да го използвате само в работеща директория.   -  person David W.    schedule 30.04.2014
comment
Благодаря за бързите коментари. Опитвам svnsync сега локално, след което правя svndump. Надяваме се, че мога да разбера проблема чрез svndump и/или да го поправя ръчно, преди да импортирам дъмпа отново като репо и да опитам още един git svn клонинг   -  person Moataz Elmasry    schedule 30.04.2014
comment
Вече имам цялото хранилище на моя диск и се опитвам да го клонирам в git по начин, по който git е наясно със svn move/copy   -  person Moataz Elmasry    schedule 09.05.2014

Отговори (1)


arrow_upward
0
arrow_downward

В SVN разклоненията, включително стволове, са по същество просто директории в хранилище. Един от начините, по които можете да разберете къде са били файловете ви преди r599, е като стартирате log в корена на SVN repo в подробен режим. т.е. svn log -v http://myrepo/@599 Ще ви покаже всички ангажименти и пътищата, които са докоснали преди r599 в това хранилище, включително ангажименти към разклонения, преименувания и т.н. Един от тях ще бъде ангажиментът, който е преместил директории наоколо. Това ще ви помогне къде са били файловете преди този комит и можете да проверите предишната ревизия от старото й местоположение.

person ArtemB    schedule 29.04.2014