Cofanie błędnego merge’a w git-svn

Kolejny wpis oparty na ostatnich doświadczeniach z pracy. Tym razem dość klasycznie: stworzyłem w swoim repozytorium git feature brancha na podstawie brancha testing zamiast mastera. Do testing – jak łatwo się domyślić – domerdżowuję feature branche przed przekazaniem ich do testów, w związku z tym jest tam zawsze co najmniej kilka modyfikacji czekających na przetestowanie.

Niestety, zorientowałem się o tym dopiero po merge’u ww. feature brancha do mastera oraz wykonaniu git svn dcommit  (korzystam z git-svn), więc całość została nie tylko u mnie, ale też poszła do SVN-a. Sam git reset do commita sprzed merge’owania niewiele pomógł, ponieważ każdy git svn rebase i tak wracał do pierwotnego ustawienia HEAD.

Na początek, żeby pozbyć się nieprzetestowanych zmian z repozytorium SVN-a, wygenerowałem odwrotnego diffa:

git diff --no-prefix HEAD HEAD~1 > ~/revert.diff

I spatchowałem kod w masterze:

patch -p0 < ~/revert.diff

Po czym dodałem i scommitowałem zmiany w masterze oraz wypchnąłem je do SVN-a przez:

git svn dcommit

(można to było zrobić poprzez git reset lub git revert, jednak to był sposób, z którego mogłem skorzystać bez przeglądania dokumentacji, a ciągle istniało ryzyko, że ktoś ten kod w międzyczasie pobierze)

Mając stan SVN-a sprzed błędnego merge’a, przeszedłem do wertowania internetu.

Rozwiązaniem okazało się cofnięcie HEAD w gicie do ostatniego commita sprzed merge’a:

git reset --hard commit_hash

A następnie wykonanie tego samego dla SVN-owego remote’a. W tym celu należy użyć

git svn reset -r svn_revision_id

gdzie svn_revision_id  to ID ostatniej rewizji SVN sprzed błędnego merge’a.

Dzięki temu zarówno repozytorium git, jak i lokalny remote wskazują na stan sprzed merge’a. Wykonanie:

git svn rebase

pobierze więc kolejne commity z SVN na nowo i nie będzie przestawiało HEAD-a w niepożądane miejsce.

Z racji tego, że mój feature branch posiadał błędnego rodzica, do przeniesienia zmian na mastera skorzystałem z cherry-pick:

git cherry-pick commit_hash

 

 

Chyba znalazłem swoją następną dystrybucję Linuksa

UWAGA! Ten wpis ma już 5 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Od ładnych paru lat korzystam z Mandrivy. Wersja 2007.1 była chyba szczytem formy tej dystrybucji. Korzystałem z niej krótko mimo tego, że nie było z nią większych problemów. Cały sprzęt w moim Acerze był obsługiwany out of the box, nawet tak egzotyczne rzeczy, jak klawisze walutowe czy port IrDA. Diabeł tkwił jednak w szczegółach – Mandriva 2007.1 posiadała kilka drobnych, jednak irytujących błędów. Jednym z nich była totalna zwiecha systemu przy odłączaniu z USB niektórych urządzeń, np. drukarki. Utrudniało to mobilność – chęć przeniesienia laptopa w inne miejsce musiała zostać zabita w zarodku, gdy podłączona była drukarka. Wtedy jednak jakoś sobie z tym radziłem, do czasu, gdy wyszła wersja 2008.0, a potem – 2008.1.

Ta ostatnia na dobre zawitała na moim dysku – instalacja z 2009 roku działa do dziś i to właśnie na niej cały czas pracuję. Jednak od tej wersji następował upadek tej dystrybucji. I nie chodziło jeszcze wtedy o głupie decyzje developerów. Najbardziej widoczne było to w liczbie bugów, które przelewały się przez mandrivowe fora. Wiele z nich dotyczyło również mnie, a konkretniej – mojego sprzętu.

Permanentnie przestało działać wiele rzeczy, zaś niektóre wymagały długiego grzebania w systemie, aby osiągnąć efekt z wersji poprzedniej. Przestało działać sterowanie podświetlaniem z klawiatury, przez co musiałem napisać prosty skrypt korzystający z xbacklighta. Były problemy z WiFi, które zostały częściowo rozwiązane, jednak do tej pory mam problem z łączeniem się z lepiej zabezpieczonymi sieciami. IrDA nie działa, jednak nie poświęcałem jej wiele czasu, bo nie była mi już potrzebna tak, jak wcześniej. Z Bluetooth nie da się zrobić nic poza wyszukiwaniem urządzeń. I chyba najbardziej uciążliwa usterka – przestał działać suspend2ram, przez co byłem skazany co najwyżej na hibernację.

Co rok sprawdzałem kolejne wersje Mandrivy. Było jednak tylko gorzej – z każdą wersją działało coraz mniej. Chciałem to jednak naprawić, bo wersja 2008.1 starzała się coraz szybciej, znikały też kolejne serwery hostujące repozytoria z paczkami RPM. Ściągnąłem i zainstalowałem wersję cooker z nastawieniem na zgłaszanie bugów, które najbardziej mi przeszkadzają. Jak głupi byłem, okazało się dopiero po paru tygodniach.

Developerzy Mandrivy obrali postęp za główną ideę przy tworzeniu systemu. I o ile nie mam nic przeciwko temu, o tyle oni uparcie brnęli w rozwiązania bezsensowne. W 2009.1 nie było już KDE3.5 – został on zastąpiony wczesną wersją KDE4. W ten sposób otworzono puszkę pandory.

Każdy, kto miał do czynienia z KDE4 w jego pierwszych wersjach wie, jak fatalne było to środowisko. Niestabilność i restarty były powszechne. Jednak z jakiegoś powodu, developerzy Mandrivy umieścili to środowisko jako wiodące w 2009.1, jednocześnie pozbawiając KDE3.5 w repozytoriach kluczowych do jego działania paczek. Czarę goryczy przelało także PulseAudio i pomysł na przepisanie wszystkich aplikacji z KDE3.5. Dzięki temu otrzymaliśmy Amaroka 2, paskudnego jak noc „iTunes wannabe” bez tak kluczowych opcji, jak powtarzanie utworu, losowanie czy korektor graficzny. Mimo, że 2009.1 była dla mnie nieużywalna, dodawałem na potęgę bugi w Bugzilli Mandrivy. Bez skutku – większość błędów pozostała, niektóre po prostu zostały olane mimo, że problem nie zniknął.

Po tym wydarzeniu okopałem się w wersji, z której korzystałem – 2008.1. Zrobiłem sobie mirror repozytorium na płytach DVD na wszelki wypadek. I korzystam z niej do dzisiaj.

Jednak parę dni temu zainteresowałem się znowu najnowszą wersją Mandrivy. Rozczarowałem się – 2011 jest tak samo beznadziejna. Czytałem tez na temat zawirowań ws. tej dystrybucji i kolejnych przetasowaniach. Jeszcze pod koniec poprzedniego roku obiecywano „odrodzenie” Mandrivy i wydanie wersji 2012 w marcu. Tak, marzec minął, a oficjalne wiki dystrybucji milczy. Jestem prawie pewien, że Mandriva już umarła.

W internecie pojawiały się jednak przebąkiwania o forku Mandrivy o nazwie Mageia. Z nudów postanowiłem ściągnąć LiveCD pierwszej wersji.

Do tej pory nie mogę wyjść z zachwytu. KDE jest używalne, jest Clementine zamiast Amaroka 2. WSZYSTKO działa tak, jak w Mandrivie 2007.1, a nawet lepiej. WiFi poprosiło tylko o ścieżkę do firmware, i zaczęło sygnalizować swoją obecność diodą na obudowie, która nie świeciła od paru ładnych lat, sterowanie podświetleniem działa, IrDA się odzywa, bluetooth działa natychmiast po wtyknięciu adaptera na USB. Działa też suspend2ram. I to wszystko od razu po uruchomieniu systemu z LiveCD.

Zacząłem śledzić rozwój Magei, jako, że za miesiąc ma wyjść druga jej wersja. I jeżeli będzie tak dobra, jak poprzednia, to na pewno na długo u mnie zagości. O ile oczywiście nie wezmą przykładu ze swojego pierwowzoru. :>

Mistrzowie developerki i naprawiania błędów

UWAGA! Ten wpis ma już 8 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Jakiś czas temu, przeżywając kryzys dystrybucyjny systemu Linux, zacząłem eksperymentować z cookerem systemu Mandriva 2009.1. Wersja rozwojowa, więc zamiast narzekać, zacząłem karmić ichnią Bugzillę zauważonymi błędami i propozycjami ulepszeń. Gdy na początku zaczęli poprawiać drobne niedopatrzenia, byłem pełen nadziei, że zaczną coś robić z pozostałymi, poważniejszymi. Dopiero teraz zdałem sobie sprawę, jaki byłem głupi.

To, że Mandriva 2009.1 jest totalną porażką i krokiem wstecz, jest oczywiste. W dniu premiery nawet najwierniejsi fani na wszystkim znanych mi forach łapali się za głowy, że wydano taki bubel. I pewnie jest to wynikiem wyścigów z Ubuntu, które również wydaje nową wersję w kwietniu. I tak oto w 2009.1 KDE4.2 jest już systemem wiodącym do tego stopnia, że KDE3 w repozytoriach pozbawiono go połowy aplikacji. Nie ma starego Amaroka, nie ma KPowersave, nie ma nawet prostego KMiksa. Nie muszę chyba dodawać, że aplikacje backportowane mulą niemiłosiernie (a szczytem jest już to, że po zmianie głośności za pomocą klawiszy funkcyjnych laptopa muszę czekać 2-3 sekundy na reakcję systemu). Do tego dochodzi masa innych, poważnych błędów: po rekonfiguracji system dobiera zły moduł do obsługi WiFi, pojawiają się śmieci w polach tekstowych aplikacji KDE3, itp. No cóż – „to tylko cooker” – myślałem. Jednak moje błędy nadal wisiały na Bugzilli.

Ostatnio jednak zacząłem dostawać optymistycznie zatytułowane maile z ww. systemu, zawierające w sobie „RESOLVED”. Ucieszony zacząłem czytać raporty, jednak mocno tego żałowałem. Otóż zgłoszony przeze mnie bug o tym, iż po instalacji KDE3 z repozytorium, KBluetooth nie wykrywa adaptera BT na USB, został rozwiązany. Tyle, że z etykietą „WONTFIX”. Oto słowa genialnego developera:

we will remove it from cooker, it doesn’t work with bluez4

Cóż to oznacza? Ano to, że KDE3 w Mandriva 2009.1 zostanie praktycznie pozbawiony możliwości korzystania z BT – KBluetooth4 nie działa bowiem na starym KDE. Naprawdę, jestem pełen podziwu dla geniuszu pomysłowych developerów. Tylko życzyć takich innym dystrybucjom.

Dzisiaj dostałem jednak kolejny mail, podobnie zatytułowany do poprzedniego. Tym razem chodzi o Amaroka 1.4.10, czyli ostatnią stabilną wersję „starego” Amaroka. Sprawa zupełnie niekontrowersyjna, ponieważ nie ma chyba osób, które używałyby z powodzeniem Amaroka 2. Paskudny, iTunesowy wygląd, brak takich opcji, jak powtarzanie, losowanie, korektor graficzny (!). Do tego bugi, jak nieprawidłowa obsługa Last.fm, brak obsługi podcastów czy urządzeń muzycznych, brak automatycznego tagowania za pomocą MusicBrainz. Nie da się tego po prostu używać. Ale mimo to, developerzy są pełni wiary w nowy, słuszniejszy produkt i:

We won’t add back amarok 1.4 on cooker.

OK, developerom Amaroka się poprzewracało w dupach, wydając stabilną, nową wersję programu, który nie ma nawet połowy funkcji poprzedniego. Ale to poprzewracanie widocznie się udziela.

Nie wiem, kiedy to się skończy, bo póki co jest coraz gorzej. I wiem, że zaraz zlecą desktopowcy mówiąc, że u nich wszystko działa. OK, ale umówmy się – na desktopie to mi wszystko działało od czasów Auroksa 10. I działa do tej pory, nawet na najtańszych płytach głównych i chińskich kościach do wszystkiego. Tyle, że nie o to tu chodzi, bo pojawia się wyzwanie, jak laptop i kilka funkcji więcej, i już są problemy.

Nie rozumiem też obrzydzenia developerów do poprzednich wersji aplikacji. Co jest złego w KDE3? I dlaczego mam używać KDE4.2, skoro poprzednia wersja działa u mnie dość szybko i bezproblemowo? OK, może i 4.2 jest zoptymalizowany, napisany od nowa, przyspieszony. Tyle, że ja tego zupełnie nie zauważam. Na KDE3 w Firefoksie potrafię mieć otwartych 15 kart z flashami i oglądać płynnie filmy na nich. W KDE4.2 otworzę sobie jeden teledysk + 2 inne karty, niezawierające flasha, i już zamiast filmu mam animację poklatkową.

Developerzy radzą na „starszych” sprzętach instalować jakieś śmieszne i biedne środowiska. OK, ale ja wcale nie mam zegara procesora taktowanego 233 MHz i 64 MB RAM-u. Mam te 1,73 GHz i 512 MB, więc dlaczego nie wystarcza to do swobodnej pracy? Nie da się? Widocznie się da, skoro KDE3 sobie radzi. No ale cóż, z obecnym myśleniem, życzę developerom powodzenia. Bo jeszcze trochę, a nie będzie się dało Mandrivy używać (nie, nie chcę zmieniać dystrybucji, za stary jestem).

Póki co, mam idealnie skonfigurowaną wersję 2008.1 oraz ściągnąłem na dysk repozytorium dla niej. Nagram na płyty i chyba zostanę, dopóki nie zmienię sprzętu (a nie zapowiada się, bo po prostu nie widzę potrzeby). A repozytorium się przyda, gdyby autorom z dnia na dzień przyszło na myśl, że 2008.1 to już wiekowa jest i „deprecated”.

PulseAudio jego mać

UWAGA! Ten wpis ma już 9 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

To jest chore i z dnia na dzień zaczyna mnie coraz bardziej denerwować. PulseAudio – na cholerę było to wprowadzać, skoro same problemy z tego powodu? Flash 9 nie działa z dźwiękiem, Flash 10 sypie się na niektórych (jak np. na last.fm) stronach, pomijając już fakt, że jest niedopracowany, na Skype nie da się normalnie pogadać, bo albo dźwięk się tnie, albo jest niesamowicie ściszony (mimo wszystkich suwaków w mikserze na max, również tych od podbicia wejść), gry zawieszają się przy wychodzeniu, przesunięcia dźwięku względem obrazu, MPLayer wyświetla film przez 1 s, po czym wisi.

I mimo, że wpis traktuje o PA, to tak się dzieje ostatnio ze wszystkim – jądro wycudowane, obsługa ACPI już nie broni nawet resztek pozorów działania. I co ciekawe – to wszystko działało bez problemu w Mandriva 2007.1, czyli ponad rok temu! Tyle, że wrócić do niej nie mogę, bo po pierwsze – miała bug powodujący zawieszanie komputera po odpięciu drukarki na USB, a po drugie – kiepsko było z obsługą WPA, a sieci nim zabezpieczonej używam przecież na uczelni.

Paranoja. To już nie jest ten sam Linux, co kiedyś. Teraz używam go za karę. Najgorsze jest tylko to, że tak samo traktuję Windowsa (może nawet gorzej). I nie mam alternatywy.

Moja aktówka w Linuksie (KDE)?

UWAGA! Ten wpis ma już 10 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Pamiętam, jak jeszcze za czasów Windowsa 95 na moim pierwszym komputerze, bawiłem się w synchronizację danych na dyskietce za pomocą windowsowej „Mojej aktówki”. Wtedy to była zabawa, jednak teraz przydałoby się takie rozwiązanie, ale już na Linuksie.

Szukałem trochę w internecie, jednak najczęściej polecanym rozwiązaniem jest użycie rsynca z linii komend lub skryptu wykorzystującego tenże program. Ja szukam jednak czegoś pod X-y, najlepiej dla KDE. Używa ktoś czegoś takiego i mógłby polecić?

Dandys IM v0.1 :)

UWAGA! Ten wpis ma już 10 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Ostatnimi czasy z nudów wziąłem się wreszcie za naukę socketów w C++. Miałem to już zrobić na początku maja, mam nawet wydrukowane samouczki, jednak myślę, że to właśnie one mnie do tego zniechęcały. A to nie był← pisane pod kątem C++, a to były zbyt obszerne i za dużo w nich było teorii. Dopiero kolejne poszukiwania (bodajże przedwczorajsze) naprowadziły mnie na właściwy trop. I tak oto, aby poznać sockety w praktyce, postanowiłem napisać sobie pseudokomunikator – Dandys IM. 😉

Póki co ma on tylko funkcję serwera (klienta mi się dopisać nie chciało, dlatego robi z niego teraz Telnet) i parę błędów (m.in. taki, że wiadomości pojawiają się czasem dopiero po wysłaniu wiadomości przez nas), ale mi to wystarczyło, żeby się przekonać, jak to fajnie, gdy mój pierwszy program z socketami potrafi porozumiewać się ze światem. 🙂

Niżej zamieszczam źródełko programu, jak komuś się chce, to wiadomo, co robić (nie wiadomo? no to: g++ socket_server.cpp -o socket_server). Jakby komuś się aż tak nudziło i poprawił buga, o którym pisałem, to proszę o kontakt.

I na koniec podziękowania dla testerów, których to często nękałem ostatnio:

Dzięki chłopaki za czas!

I oczywiście dokumenty, z których korzystałem przy nauce. Polecam ściągnięcie obydwu, wydrukowanie i parę godzin analizy.