Używanie git-svn (lub podobnego) * just* do pomocy przy łączeniu svn?

Próba odpowiedzi na moje pytanie: używanie git dla svn merges wydaje się obiecujące.

Aktualizacja: to nie tylko obiecujące, to wielki sukces. W skrócie, Linus miał rację.

Właśnie zakończyliśmy ogromne połączenie 2 gałęzi svn, które były osobno od 1,5 roku; pliki 3K zostały zmienione, mamy mnóstwo konfliktów w svn (~800 myślę).

Znalazłem git & Git-svn a life saver:

• Automatyczne rozwiązywanie konfliktów: na początek, dało dużo mniej skonfliktowanych plików (~half I think)
• niewiarygodna wydajność
• doskonały model repo/rozgałęziania, elastyczne przepływy pracy: łatwe eksperymentowanie z różnymi podejściami, takimi jak łączenie kawałek po kawałku(w czasie), zawsze sprawdzanie zdrowego rozsądku(kompilacja, itp.); gdy pojawią się problemy: po prostu wróć. Zawsze możesz zrobić krok w tył, gdy zajdzie taka potrzeba.
• użyteczność, świetne oprzyrządowanie:
  • git-log (i podstawowe opcje git-rev-parse), nic nie może być bardziej potężne niż to. Jest również poręczny: -p daje diffy za jednym razem; w svn dostajesz log, a następnie znajdź diff dla tego "revision-1: revision", lub użyj niezgrabnego interfejsu użytkownika. Wyszukiwanie po dodaniu/usunięciu łańcucha do repo, wyszukiwanie wielu gałęzi jednocześnie
  • gitk: niezwykle przydatne do wizualizacji historii gałęzi, w połączeniu z dużymi możliwościami wyszukiwania. Nie widziałem czegoś takiego w innych narzędziach, zwłaszcza nie tak szybko jak to. Nevermind it 's in Tk, it' s just brilliant
  • git gui: działa dobrze, nawet jeśli nie sexiest-wielka pomoc dla nowicjusza, aby odkryć rzeczy
  • Cud. Tak, wykrywa skąd pochodzi oryginalny segment (Kopiuj i wklej itp.)]}
  • mergetool: o wiele przyjemniejsze doświadczenie niż kopanie dużego svn merge, które potem zatrzymuje się za każdym razem (tj. co 5 minut) wchodzi w konflikt, naciśnij "(P) ostpone", a następnie ręcznie poluj na skonfliktowane pliki później. Preferował smak tego zintegrowanego w git gui (potrzebował do tego małego plastra). Znalezione integracje zewnętrzne narzędzia różnicowe lepiej konfigurowalne niż w svn.
  • sterowniki scalające i drobnoziarnista kontrola nad nimi
  • rebase dozwolone odfiltrowywanie części Messiera z historii svn
• dystrybucja: nie ma potrzeby przychodzić do biura podczas pracy nad tym, może pauzować i robić postępy krok po kroku w pociągu/samolocie itp..
  • pendrive zUnison wykonane synchronizacji pracy domu kawałek ciasta
  • to nie byłoby możliwe bez szalona kompresja Gita (5-letni projekt z 26K commitów, mnóstwo gałęzi i plików binarnych, trunk svn checkout: 1.9 Gb = > wszystko to w pełnej repo git: 1.4 Gb!)

Więc to naprawdę może zmienić koszmar w radość-zwłaszcza jeśli lubisz się uczyć (co wymaga trochę wysiłku w tym przypadku - myślę, że jak nauka motocykla po rowerze).

Mimo że nie mogę zmusić wszystkich w firmie do natychmiastowej zmiany-naprawdę nie zamierzałem. Ponownie, git-svn ratuje nas przez "zanurzenie palca pierwszy" podejście.. Ale widząc reakcje kolegów, zmiana może nastąpić znacznie wcześniej, niż ktokolwiek się spodziewał:)

Powiedziałbym - nawet jeśli zapomnimy o merges & commits, ten materiał jest już świetny jako nakładka tylko do odczytu dla zapytań, wizualizacji, kopii zapasowych itp..

Zastrzeżenie:

" Do not dcommit Git merge commits to repozytorium Subversion. Subversion nie obsługuje połączeń w ten sam sposób jako Git, a to spowoduje problemy. Oznacza to, że powinieneś zachować swój Git historia rozwoju (tj. nie łączenie z innych gałęzi, tylko rebasing)." (ostatni akapit http://learn.github.com/p/git-svn.html )

Kolejnym doskonałym źródłem jest Pro Git book , sekcja 'Switching Active Branches' w zasadzie mówi, że scalanie działa, ale dcommit będzie przechowywać tylko zawartość scalenia, ale historia będzie zagrożona (co łamie kolejne scalenia), więc po scaleniu należy porzucić gałąź roboczą. W każdym razie to ma sens, a w praktyce łatwo jest uniknąć pułapek tutaj.. w svn odkryłem, że ludzie zwykle nie łączą się ponownie i tak, więc może to być postrzegane jako krok wstecz, jeśli w ogóle pochodzisz ze świata Gita.

W każdym razie, komisariat pracował dla mnie. Zrobiłem to na własnym svn workbranch, który przechowywałem tylko do tego, więc uniknąłem dodatkowych konfliktów w tym czasie. Jednak postanowiłem zrobić ostateczne połączenie z ta gałąź robocza do bagażnika svn w svn (po zsynchronizowaniu wszystkiego w git); --ignore-ancestry dała tam najlepsze wyniki.

Update: jak się później dowiedziałem, kilka ostatnich kroków powyżej (extra svn branch i merge--ignore-ancestry) można łatwo uniknąć, po prostu utrzymując gałąź, którą dcomitujesz z liniowego. Jak mówi Gabe poniżej, merge --squash po prostu tworzy prosty głupi commit przyjazny svn. Po prostu kiedy gotowy z ogromnymi merge(s) na moim lokalnym oddziale (co może potrwać dni / tygodnie), chciałbym teraz tylko:

git checkout -b dcommit_helper_for_svnbranch  svnbranch
git merge --squash huge_merge_work_with_messy_nonlinear_history
git commit 'nice merge summary' # single parent, straight from the fresh svnbranch
git dcommit

Wiem, że Śledzenie połączenia nie będzie działać dobrze od strony svn, dopóki nie przełączymy się w pełni. Nie mogę się doczekać.

---

UPDATE: @Kevin poprosił o więcej szczegółów na temat całego procesu łączenia gałęzi svn.. Jest tam wiele artykułów, postów, ale jako początkujący znalazłem niektóre z mylących/wprowadzających w błąd / nieaktualnych.. Tak czy siak, jak to robię w dzisiejszych czasach (oczywiście, utknąłem z git-svn po tym romansie; tak jak jakiś świeżo zainfekowany kolegów)..

git svn clone -s http://svn/path/to/just-above-trunk  # the slowest part, but needed only once ever..you can every single branch from the svn repo since revision #1. 2) 
git svn fetch          # later, anytime: keep it up to date, talking to svn server to grab new revisions. Again: all branches - and yet it's usually a faster for me than a simple 'svn up' on the trunk:)    
# Take a look, sniff around - some optional but handy commands:
git gui   &    # I usually keep this running, press F5 to refresh
gitk --all     # graph showing all branches
gitk my-svn-target-branch svn-branch-to-merge    # look at only the branches in question
git checkout -b my-merge-fun my-svn-target-branch  # this creates a local branch based on the svn one and switches to it..before you notice :)
# Some handy config, giving more context for conflicts
git config merge.conflictstyle diff3
# The actual merge.. 
git merge  svn-branch-to-merge    # the normal case, with managable amount of conflicts
# For the monster merge, this was actually a loop for me: due to the sheer size, I split up the 2 year period into reasonable chunks, eg. ~1 months, tagged those versions ma1..ma25 and mb1..mb25 on each branch using gitk, and then repeated these for all of them
git merge ma1   # through ma25
git merge mb1   # through mb25
# When running into conflicts, just resolve them.. low tech way: keep the wanted parts, then "git add file" but you can
git mergetool   # loops through each conflicted file, open your GUI mergetool of choice..when successful, add the file automatically.
git mergetool  my-interesting-path # limit scope to that path

W zasadzie wolałem użyć wbudowanej integracji mergetool ' git gui (kliknij prawym przyciskiem myszy plik w konflikcie). Jest to jednak nieco ograniczone, więc zobacz moją małą łatkę powyżej, która pozwala na wtyczkę skryptu powłoki, w której możesz wywołać cokolwiek mergetools wolisz (próbowałem różnych z nich czasami równolegle, ponieważ spowodowały zaskakującą ilość żalu.. ale normalnie utknąłem z kdiff3..

Gdy proces scalania przebiega prawidłowo (bez konfliktu), commit merge jest wykonywane automatycznie; w przeciwnym razie rozwiązujesz konflikty, a następnie

git commit  # am usually doing this in the git gui as well.. again, lightning fast.

Ostatnia faza.. Zauważ, że do tej pory mieliśmy tylko lokalne commity, nie rozmawiając jeszcze z serwerem svn. Jeśli nie użyłeś --squasha lub innych sztuczek, teraz kończysz z wykresem, na którym twój commit merge ma 2 rodziców: końcówki gałęzi svn-mirror. Teraz jest to zwykle gotcha: svn może przyjmować tylko historię liniową.. tak więc' Git-svn ' upraszcza to poprzez upuszczenie drugiego rodzica (svn-branch-to-merge w powyższym przypadku).. więc prawdziwe śledzenie scalenia zniknęło po stronie svn..ale poza tym jest w porządku w tym przypadku.

Jeśli chcesz bezpieczniejszy / czystszy sposób, tutaj pojawia się mój wcześniejszy fragment: po prostu wykonaj ostateczne połączenie z -- squash. Przystosował wcześniejszy do tego przepływu:

git checkout -b dcommit_helper_for_svnbranch my-svn-target-branch  # another local workbranch.. basically needed as svn branches (as any other remote branch) are read-only
git merge --squash my-merge-fun  
git commit 'nice merge summary' # single parent, straight from the fresh svn branch
git dcommit  # this will result in a 'svn commit' on the my-svn-target-branch

Ups, to robi się zbyt długo, zatrzymując się przed zbyt późno.. Powodzenia.