git-svn: jaki jest odpowiednik `svn switch --relocate`?

Repozytorium svn, które dubluję przez git-svn, zmieniło adres URL.

W Vanilla SVN po prostu byś to zrobił svn switch --relocate old_url_base new_url_base.

Jak mogę to zrobić za pomocą git-svn?

Po prostu zmiana adresu URL svn w pliku konfiguracyjnym kończy się niepowodzeniem.

To całkiem dobrze rozwiązuje moją sytuację:

https://git.wiki.kernel.org/index.php/GitSvnSwitch

Sklonowałem za pomocą file://protokołu i chciałem przełączyć się na http://protokół.

Kuszące jest edytowanie urlustawienia w [svn-remote "svn"]sekcji .git/config, ale samo to nie działa. Ogólnie musisz postępować zgodnie z następującą procedurą:

1. Przełącz ustawienie svn-remote urlna nową nazwę.
2. Biegnij git svn fetch. To musi pobrać co najmniej jedną nową wersję z svn!
3. Zmień ustawienie svn-remote z urlpowrotem na oryginalny adres URL.
4. Uruchom, git svn rebase -laby wykonać lokalną rebase (ze zmianami wprowadzonymi podczas ostatniej operacji pobierania).
5. Zmień ustawienie svn-remote z urlpowrotem na nowy adres URL.
6. Teraz git svn rebasepowinno znowu działać.

Dusze żądne przygód mogą chcieć spróbować --rewrite-root.

Możesz sprawdzić, czy poniższe elementy działają poprawnie:

1. Jeśli svn-remote.svn.rewriteRootnie istnieje w pliku konfiguracyjnym ( .git/config):

   git config svn-remote.svn.rewriteRoot <currentRepositoryURL>
   

2. Jeśli svn-remote.svn.rewriteUUIDnie istnieje w pliku konfiguracyjnym:

   git config svn-remote.svn.rewriteUUID <currentRepositoryUUID>
   

   currentRepositoryUUIDMożna otrzymać z .git/svn/.metadata.

3. git config svn-remote.svn.url <newRepositoryURL>

Niestety większość linków w tych odpowiedziach nie działa, więc zamierzam zduplikować część informacji z git wiki na przyszłość.

To rozwiązanie zadziałało dla mnie:

• Edytuj svn-remote url(lub fetchścieżkę) w, .git/configaby wskazać nową domenę / adres URL / ścieżkę

• Uruchom git git svn fetch. To musi pobrać co najmniej jedną nową wersję z svn!

• Jeśli spróbujesz git svn rebaseteraz, zostanie wyświetlony następujący komunikat o błędzie:

  Unable to determine upstream SVN information from working tree history
  

  Myślę, że dzieje się tak, ponieważ git svnjest zdezorientowany faktem, że ostatnie zatwierdzenie przed pobraniem będzie miało git-svn-idwskazanie na starą ścieżkę, która nie pasuje do tej znalezionej w .git/config.

• Aby obejść ten problem, zmień svn-remote url(lub fetchścieżkę) z powrotem do oryginalnej domeny / adresu URL / ścieżki

• Teraz uruchom git svn rebase -lponownie, aby wykonać lokalną rebase ze zmianami wprowadzonymi podczas ostatniej operacji pobierania. Tym razem to będzie działać, bo widocznie git svnnie należy mylić z faktu, że git-svn-idod nowego szefa nie zgadza się z tym znaleźć w .git/config.

• Na koniec zmień svn-remote url(lub fetchścieżkę) z powrotem do nowej domeny / adresu URL / ścieżki

• W tym momencie git svn rebasepowinno działać ponownie!

Oryginalne informacje zostały znalezione tutaj .

Git svn w dużym stopniu opiera się na adresie URL svn. Każde zatwierdzenie, które jest importowane z svn git-svn-id, zawiera adres URL svn.

Prawidłową strategią relokacji jest zadzwonienie git-svn clone nowego repozytorium i połączenie zmian z tym nowym zamknięciem. Aby uzyskać bardziej szczegółową procedurę, zobacz ten artykuł:

http://www.sanityinc.com/articles/relocating-git-svn-repositories

git filter-branch

Ten skrypt , zaczerpnięty z wpisu na blogu , zadziałał dla mnie. Podaj stary i nowy adres URL repozytorium jako parametr, tak jak w przypadku svn switch --relocate.

Skrypt wywołuje git filter-branchzastąpienie adresów URL Subversion w git-svn-idkomunikatach o zmianach .git/config, aktualizuje , a także aktualizuje git-svnmetadane, odtwarzając je za pomocą git svn rebase. Chociaż git svn clonemoże być bardziej niezawodnym rozwiązaniem, filter-branchpodejście to działa znacznie szybciej w przypadku dużych repozytoriów (godziny w porównaniu z dniami).

#!/bin/sh

# Must be called with two command-line args.
# Example: git-svn-relocate.sh http://old.server https://new.server
if [ $# -ne 2 ]
then
  echo "Please invoke this script with two command-line arguments (old and new SVN URLs)."
  exit $E_NO_ARGS
fi

# Prepare URLs for regex search and replace.
oldUrl=`echo $1 | awk '{gsub("[\\\.]", "\\\\\\\&");print}'`
newUrl=`echo $2 | awk '{gsub("[\\\&]", "\\\\\\\&");print}'`

filter="sed \"s|^git-svn-id: $oldUrl|git-svn-id: $newUrl|g\""
git filter-branch --msg-filter "$filter" -- --all

sed -i.backup -e "s|$oldUrl|$newUrl|g" .git/config

rm -rf .git/svn
git svn rebase

git_fast_filter

Jednak szybciej niż git-filter-branch(tj. Minuty zamiast godzin), ale podobnie w duchu, jest użycie git_fast_filter. Wymaga to jednak nieco więcej kodowania i nie istnieje żadne schludne, gotowe rozwiązanie. W przeciwieństwie do git-filter-branchtego spowoduje to utworzenie nowego repozytorium ze starego . Zakłada się, że masterwskazuje na ostatnie zatwierdzenie SVN.

1. Klon git_fast_filterz repo Gitorious.
2. Utwórz skrypt Pythona w tym samym katalogu, w którym sklonowałeś git_fast_filterna podstawie tego Gist , ustaw wykonywalny bit za pomocą chmod +x. Dostosuj stare i nowe ścieżki repozytorium. (Treść skryptu jest również wklejona poniżej).
3. Zainicjuj nowe repozytorium docelowe za pomocą git init, zmień katalog roboczy na to nowe repozytorium.

4. Wykonaj następującą potokę:

   (cd path/to/old/repo && git-fast-export --branches --tags --progress=100) | \
       path/to/git_fast_filter/commit_filter.py | git-fast-import
   

5. Skopiuj .git/configi być może inne odpowiednie pliki w formacie.git/info ze starego repozytorium do nowego repozytorium.

6. Usuń .git/svn.

7. Zwróć uwagę git-svnna nowe mapowanie numerów wersji

   1. Wykonać git branch refs/remotes/git-svn master

      • Twoje piloty git-svn można nazwać inaczej niż refs/remotes/git-svnskonsultować .git/config, svn-remotesekcje

   2. Wykonaj git svn info. Jeśli to polecenie zawiesza się, coś jest nie tak. Powinien odbudować mapowanie numerów wersji.

   3. Usuń fałszywą gałąź refs/remotes/git-svn, zostanie odtworzona przezgit-svn

8. Synchronizuj, dzwoniąc git svn rebase.

Poniżej znajduje się treść commit_filter.py, zamień wartości IN_REPOi OUT_REPOodpowiednio:

#!/usr/bin/python

from git_fast_filter import Commit, FastExportFilter
import re
import sys

IN_REPO = "https://svn.code.sf.net/p/matsim/code"
OUT_REPO = "https://svn.code.sf.net/p/matsim/source"

IN_REPO_RE = re.compile("^git-svn-id: %s" % re.escape(IN_REPO), re.M)
OUT_REPO_RE = "git-svn-id: %s" % OUT_REPO

def my_commit_callback(commit):
  commit.message = IN_REPO_RE.sub(OUT_REPO_RE, commit.message)
  sys.stderr.write(".")

filter = FastExportFilter(commit_callback = my_commit_callback)
filter.run()

Powyższe git svn rebase -lrozwiązanie u mnie nie działa. Postanowiłem zająć się tym inaczej:

1. Sklonuj stare repozytorium SVN do repozytorium git, olda nowe repozytorium SVN do repozytorium gitnew
2. Pobierz olddonew
   • cd new
   • git fetch ../old
   • git tag old FETCH_HEAD
3. Rebase newna szczycie old(powinno się powieść, ponieważ drzewa w korzeniu newi na końcu oldsą identyczne)
   • git checkout master(Zakłada się, że mastergałąź wskazuje na główkę SVN. Tak będzie w przypadku czystego klonu; w przeciwnym razie dcommit przed rozpoczęciem).
   • git rebase --root --onto old
4. Przebuduj metadane git-svn z, newaby uwzględnić rebase
   • git update-ref --no-deref refs/remotes/git-svn master(dostosuj zdalny numer referencyjny w zależności od tego, jak sklonowałeś, np. może to być refs/remotes/svn/trunk)
   • rm -r .git/svn
   • git svn info

Opierając się na niektórych innych odpowiedziach na to pytanie, wymyśliłem skrypt Ruby, który obsługuje relokację git-svn. Możesz go znaleźć na https://gist.github.com/henderea/6e779b66be3580c9a584 .

Obsługuje relokację bez sprawdzania innej kopii, a nawet obsługuje przypadek, w którym występują niewysłane zmiany w jednej lub kilku gałęziach (ponieważ łamie to zwykłą logikę). Używa rzeczy z odpowiedzi git filter-branch (dla głównej logiki) i odpowiedzi o kopiowaniu gałęzi z jednej instancji repozytorium do drugiej (do kopiowania gałęzi z niezapchniętymi zmianami).

Używałem tego do przenoszenia kilku repozytoriów git-svn, które mam do pracy, a ta wersja skryptu (przeszedłem przez niezliczone iteracje) wydaje się działać dla mnie. Nie jest superszybki, ale wydaje się obsługiwać wszystkie napotkane przypadki i skutkować w pełni przeniesionym repozytorium.

Skrypt daje możliwość utworzenia kopii repozytorium przed wprowadzeniem jakichkolwiek zmian, więc można użyć tej opcji do utworzenia kopii zapasowej. Utworzenie kopii jest wymagane, jeśli masz cofnięte zmiany w jakichkolwiek gałęziach.

Skrypt nie używa żadnych klejnotów ani innych bibliotek, które nie są zawarte w normalnej instalacji MRI Ruby. Używa bibliotek readline i fileutils zawartych w MRI.

Mam nadzieję, że mój skrypt przyda się komuś innemu. Zapraszam do wprowadzania zmian w skrypcie.

UWAGA: Testowałem ten skrypt tylko z git 2.3.0 / 2.3.1 i Ruby 2.2.0 na OS X 10.10 Yosemite (ponieważ jest to środowisko, którego używam), ale spodziewałbym się, że będzie działał również w innych środowiskach. Nie ma jednak gwarancji dotyczących systemu Windows.