2009-07-20 3 views
6

To pytanie jest podobne do this one i this one, ale scenariusz jest nieco bardziej złożony.Jak zachowuje się git-svn z repozytoriami svn, które zmieniły układ?

Zacząłem kilka lat temu z prywatnym repozytorium svn (używam głównie do współdzielenia plików konfiguracyjnych i tym podobnych między różnymi maszynami). Nie byłem zbyt ostrożny z układem repozytorium (gdzie gałęzie, idę, itp.), Więc z czasem bardzo się zmienił. To był oczywiście błąd, ale teraz jest już za późno. Niedawno zmigrowałem go do bardziej standardowego układu svn trunk/branches/tags, głównie za pomocą poleceń svn move, ale oczywiście w repozytorium nadal jest stara historia (i, szczerze mówiąc, trochę bałaganu) .

Chciałbym teraz przekonwertować to na stałe do repozytorium git. Próbowałem już używać git-svn, ale wydaje się, że obsługuje on tylko sytuacje, w których przestrzegano konsekwentnej konwencji trunk/branch/tag (tak, można podać alternatywne nazwy, ale pojawia się tylko jedna dla każdego). Spora część historii mojego repozytorium ma efektywnie trunk w katalogu głównym repozytorium, na przykład tagami/i branch/as sub-dirs.

Jaki jest najlepszy sposób na poradzenie sobie z tym wszystkim? Idealnie chciałbym, aby repozytorium git, w którym się znalazłem, miało przynajmniej dostęp do całej historii, nawet jeśli gałęzie i znaczniki nie są właściwie reprezentowane jako pojęcia pierwszej klasy w git.

Dokładniej, w jaki sposób svn-git będzie obsługiwał pliki spoza podanych poniżej katalogów trunk/branches/tags? Moje dotychczasowe obserwacje polegają na tym, że czasami je pomija (zdecydowanie nie w porządku), a innym razem dodaje je do nowego repozytorium.

Wszelkie uwagi będą mile widziane.

+0

zapytać, jak to będzie się zachowywać, ale także powiedzieć, że próbowałem. Szczególne przykłady niepożądanych zachowań, które zaobserwowałeś, byłyby pomocne. Git jest zwykle niesamowicie dobry w obsłudze złożonych połączeń, np. Zmieniając i przesuwając poddrzewo w tym samym zatwierdzeniu. –

+0

OK - próbowałem tego. Przyznaję, że mogłem nie zagłębić się w wyniki całkowicie, ale moje powierzchowne obserwacje były z pewnością takie, że git-svn wydawało się zawierać katalogi z katalogu głównego svn (tj. Poza katalogami trunk/branches/tags), ale nie inne. Byłem zdezorientowany, dlaczego. git jest w stanie obsłużyć złożone scalenia, ale myślę, że to pytanie dotyczy raczej git-svn niż samego Git. –

+0

użyj znacznika ['svn'] zamiast znacznika [' subversion'] http://meta.stackexchange.com/questions/2601/batch-retag-request-merge-svn-and-subversion –

Odpowiedz

2

Z mojego doświadczenia wynika, że ​​jedynym sposobem radzenia sobie z tym problemem jest śledzenie położenia repozytorium przez cały czas i utworzenie osobnego klonu git-svn dla każdego okresu, w którym projekt pozostał w jednym miejscu.

Po utworzeniu repozytoriów na różne etapy w czasie (lub przynajmniej tak daleko, jak to tylko możliwe) można przeszczepiać repozytoria razem.

Utworzyłem screencast wykazując tę ​​technikę tutaj:

http://blog.tfnico.com/2010/10/gitsvn-6-grafting-together-svn-history.html