Poniżej pokażę rozwiązanie następującego problemu: “jestem programistą, znam i lubię Gita, ale w mojej firmie używa się SVNa”. Z pomocą przychodzi rozszrzenie git-svn, które umożliwia obustronną synchronizację repozytoriów. Rozpoczynamy od instalacji w systemach z rodziny Debian:

sudo apt-get install git-svn

Następnie inicjalizujemy repozytorium:

mkdir repo
cd repo
git svn init svn://repo.path/trunk
git svn fetch -r HEAD

Po tych czynnościach w folderze repo mamy już źródła naszego projektu. Możemy przystąpić do kodowania. Standardowo procedura nie różni się od normalnego używania Gita (czyli branch’owanie, rebase’y, mergowanie). Jedynie dochodzą dwie komendy którymi synchronizujemy się z repozytorium SVN:

git svn rebase

Pobiera najnowsze zmiany z repozytorium SVN do gałęzi master (odpowiednik svn update).

git svn dcommit

Wysyła nasze najnowsze zmiany z gałęzi master do repozytorium SVN (odpowiednik svn commit).

Warto jeszcze nadmienić o często spotykanej metodyce pracy z Gitem, tzw. ticket-workflow. Korzystając z aplikacji zarządzania zadaniami, takiej jak Jira lub Trac, każde zadanie ma swój numer. Dla każdego zadania tworzymy osobny branch w Gicie o nazwie TICKET_NR-krotki-opis. Dzięki temu możemy łatwo przełączać konteksty, jeśli przyjdzie nam nagle pracować nad innym zadaniem, a także porządkować commity przez spłaszczanie ich przy mergowaniu do gałęzi master. W naszym branchu na zadanie commitujemy do woli, a mergując do mastera używamy opcji squash, która stworzy nam jeden commit. Można też użyć mechanizmu rebase z opcją interactive, dzięki któremu możemy grupować lub reorganizować commity.

Powyższe rozwiązania zostały sprawdzone w praktyce i sprawowały się bardzo dobrze, obecność SVN była praktycznie nieodczuwalna w całym procesie :-)

Więcej informacji o samym Gicie znajdziesz w artykule Konrada: GIT-owy piątek z XSolve

W ramach “Piątków z XSolve” miałem zaszczyt i przyjemność pokazać reszcie zespołu czym ten GIT jest, i dlaczego warto się nim zainteresować. Podczas prezentacji osoby bardziej obeznane w SCMach – w tym poza SVN oraz Gitem również Mercurialem – wtrącały swoje trzy grosze co zawsze jest mile widziane i bardzo pomogło ogólnej wartości prezentacji. Mam nadzieję że ta króciutka prezentacja zachęci niektórych z obecnych – lub Was, czytających bloga – do rzucenia okiem na dokumentację lub liczne poradniki dotyczące Gita – poniżej kilka dobrych linków od których można by zacząć:

• http://www.youtube.com/watch?v=4XpnKHJAok8 Wystąpienie Linusa Torvaldsa dotyczące Git
• http://whygitisbetterthanx.com – przechwalająca Git’a stronka, zestawiająca go z innymi SCM
• http://git.or.cz/course/svn.html – porównanie side-by-side z SVN
• http://git-scm.com – Strona domowa projektu

Cannot reintegrate into a working copy not entirely at infinite depth

Szybki googiel zasugerował, że to coś związane z “rzadkimi katalogami” w svn.

Zrobiłem nową kopię roboczą trunka i do niej już bez problemów udało się wykonać reintegrate.

svn: Cannot reintegrate from 'url://feature-branch' yet:
Some revisions have been merged under it that have not been merged
into the reintegration target; merge them first, then retry.

Wiadomość nie podsuwa oczywistego rozwiązania. Pierwszą rzeczą którą sprawdziłem było ponowne uaktualnienie mojej gałęzi trunkiem, ale to nie pomogło.
Rozwiązanie problemu znalazłem na blogu Submerged. Można tam znaleźć dokładne wyjaśnienie, skąd ten błąd (a także kilka ciekawych informacji o samym SVN – polecam). Tutaj tylko szybkie rozwiązanie, które mi zawsze pomaga (operacje wykonujemy na gałęzi):

• W korzeniu kopii roboczej wpisujemy:

svn propget svn:mergeinfo -R

• Powinniśmy dążyć do tego, żeby svn:mergeinfo istniało tylko dla korzenia kopii roboczej, np.:

. – /branches/Foo:2055-2223

• Usuwamy kolejno własność na wszystkich katalogach w głównym katalogu kopii roboczej:

svn propdel svn:mergeinfo -R nazwa_katalogu

• Znowu robimy svn propget svn:mergeinfo -R. Jeżeli widzimy tylko katalog główny (np /trunk, albo /branches/foo) to wszystko jest ok.

Możemy teraz spróbować ponownie zreintegrować naszą gałąź. Powinno działać.