Jeśli chcesz przenieść repozytorium i zachować historię, prawdopodobnie będziesz potrzebować dostępu do systemu plików na obu hostach. Najprostszym rozwiązaniem, jeśli twój backend to FSFS (domyślny w ostatnich wersjach), jest utworzenie kopii systemu plików całego folderu repozytorium.
Jeśli masz zaplecze Berkley DB, jeśli nie jesteś pewien, jaki jest twój backend lub jeśli zmieniasz numery wersji SVN, będziesz chciał użyć svnadmin, aby zrzucić stare repozytorium i załadować je do nowego magazyn. Użycie svnadmin dump
da ci kopię zapasową jednego pliku, którą możesz skopiować do nowego systemu. Następnie możesz utworzyć nowe (puste) repozytorium i użyć svnadmin load
, które zasadniczo odtworzy wszystkie zatwierdzenia wraz z metadanymi (autor, znacznik czasu itp.).
Możesz przeczytać więcej o procesie zrzutu / ładowania tutaj:
http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
Ponadto, jeśli to zrobisz svnadmin load
, upewnij się, że korzystasz z tej --force-uuid
opcji, w przeciwnym razie ludzie będą mieli problemy z przejściem do nowego repozytorium. Subversion używa UUID do wewnętrznej identyfikacji repozytorium i nie pozwala na przełączenie kopii roboczej do innego repozytorium.
Jeśli nie masz dostępu do systemu plików, mogą istnieć inne opcje stron trzecich (lub możesz coś napisać), które pomogą ci w migracji: zasadniczo musiałbyś użyć dziennika svn, aby odtworzyć każdą wersję w nowym repozytorium, i następnie popraw metadane. Będziesz potrzebować skryptów przechwytujących przed revprop-change i post-revprop-change, aby to zrobić, które zakładają dostęp do systemu plików, więc YMMV. Lub, jeśli nie chcesz zachować historii, możesz użyć kopii roboczej do importu do nowego repozytorium. Ale miejmy nadzieję, że tak nie jest.
svnrdump dump https//remote/svn/trunk > repos.dump
. W większości przypadków polecenie działa również z SVN 1.6, ale mogą wystąpić pewne problemy, zobacz dokumentację. Działa zarówno w * nix, jak i Windows.