programisty tips'n'tricks

Ten post justaddwater.dk | How To Recover Deleted Subversion Branch idealnie rozwiązuje problem, który ostatnio spotkałem. Mianowicie mamy w firmie praktykę aby usuwać branche, gdy kończy się nad nimi pracę. Jest do dobra praktyka - pozwala zachowywać porządek na liście branchy projektu.

Jednak prowadzi również do problemu, gdy po złączeniu zmian z np. trunkiem i usunięciu brancha chcemy się mimo wszystko dowiedzieć kto pracował nad którąś ze zmian - całkiem eleganckie rozwiązanie podsuwa wspomniany wyżej wpis. Myślę, że będzie pomocne nie tylko mnie i mojemu zespołowi.

Jeśli i Ty się kiedyś zastanawiałeś jak podejrzeć listę plików które zmienią się po wykonaniu svn update, to wreszcie możesz poznać odpowiedź.

Niestety zwykłe svn status -u nie działa tak, żeby pokazywało również pliki które się skonfliktują po aktualizacji a pod poniższym linkiem możecie znaleźć rozwiązanie, czyli jak poznać pełną listę zmian po aktualizacji.

Więcej we wpisie na blogu justaddwater.dk | How to make a dry-run with svn update.

Od kiedy tylko poznałem Ruby’ego polubiłem go i żadne inne języki nie są mi potrzebne - po prostu Ruby wpasował się w mój sposób pojmowania programowania. (Poza PHP i JavaScriptem w pracy :P). Podobnie moja historia wyglądała z Gitem. Mimo, że SVN był pierwszym systemem do zarządzania kodem jaki poznałem, to mam wrażenie, że dopiero Git odzwierciedla ideę zarządzania i wersjonowaniem kodu w taki sposób jak najlepiej potrafię sobie wyobrazić pracę z repozytorium kodu.

Idea stagging area, lekkie branche, lokalne repozytorium, ultraszybki dostęp do logów, blame’ów, poprzednich commitów - to wszystko pozwala naprawdę wydajnie i szybko pracować. Niestety do tej pory dane mi było używać Gita tylko do własnych projektów, ale byłem bardziej niż zadowolony.

Jeśli i wy chcecie się dowiedzieć dlaczego Git jest lepszy od obecnie stosowanego przez was systemu kontroli wersji, polecam stronę Scotta Chacon (można go było poznać na ostatnim RuPy w Poznaniu) -  Why Git is Better Than X.

A jeśli ktoś się jakoś zainteresuje bardziej Gitem, to może zajrzeć tu: git ready.