Development z Zapomnianej Strony

..:: Paweł Hofman .NET Portal ::..

Dziś ukazała się długo oczekiwana nowa wersja moich bibliotek CodeTitans Libs v1.5. Zawiera ona szereg poprawek oraz nowych funkcjonalności.

Niewtajemniczonym, podpowiem, że służą one do: obsługi odczytu i zapisu w formacie JSON, wymiany danych z użyciem protokołu Bayeux oraz zawierają inne funkcjonalności potrzebne przy przenoszeniu programów z iPhone’a do Windows Phone 7.

Zapraszam do pobierania tutaj.



Kolejną ciekawostką, którą chciałbym omówić są zdalne repozytoria i dostęp do nich. O ile są to repozytoria tego samego typu (czyli np. Subversion połączone z Subversion – jako externals, czy Git pracujący z Gitem – jako submodules), to nie ma to większego znaczenia i obsługa jest bezproblemowa.

Ciekawsze są oczywiście krzyżówki. Jeśli przyjrzymy się bliżej pracy w Git, który musi korzystać z zewnętrznego repozytorium Subversion, to już wcale nie musi wyglądać prosto. Weźmy choćby mój projekt CodeTitans Libraries (wspomagający użycie protokołu Bayeux, standardu wymiany danych tekstowych JSON, InversionOfControl oraz udostępniający niektórych funkcjonalności znanych programistom iOS SDK w .NET-cie). Codeplex.com udostępnia go jako Subversion.

Przyjmijmy, że repozytorium Git, ma bardzo prostą strukturę złożoną z branchy master oraz develop. Pierwszy służy to przechowywania referencji stabilnych wersji kodu oraz ich etykietowania. Drugiego używamy do rozwijania i pracy nad aktualnym kodem.

Cel: gdzieś w katalogu Externals/CodeTitans chcielibyśmy mieć kod z też projektu.

W tym celu przede wszystkich będziemy potrzebowali dodatkowego brancha. Nazwijmy go codetitans_develop. Wybiegając do przodu - Git tak naprawdę skopiuje pełny kod źródłowy zewnętrznego projektu i sam będzie go wersjonował. Niestety minus jest taki, iż będzie on ten kod próbował umieścić w głównym folderze swojego własnego repozytorium, generując niezły chaos, przy złączeniu obu projektów (tego pierwotnie trzymanego w Gicie oraz nowego). Praca na dodatkowym branchu pozwoli nam zatem na wprowadzanie lokalnych zmian, np.:

  • przeniesienia plików do wspomnianego folderu Externals/CodeTitans
  • dokonywania innych drobnych modyfikacji (np. gdy chcemy bezpośrednio dodać pliki do solution, bez referencjonowania projektów biblioteki CodeTitans Libraries, to może widoczność zmienić z ‘public’ na ‘internal’)

A zatem, po kolei:

  1. Dodanie nowego brancha:

    git checkout –b codetitans_develop
  2. Dodanie referencji do zewnętrznego repozytorium SVN:

    git svn init https://codetitans.svn.codeplex.com/svn -R codetitans --prefix Externals/CodeTitans/ --ignore-paths="^[^/]+/(?:branches|tags|bin)"

    - lokalizacja – codeplex.com
    - nazwa lokalna – codetitans
    - ponieważ repozytorium to ma standardową strukturę, a nas interesuje jedynie ‘trunk’ – ignorujemy pozostałe foldery
  3. Pobieramy historię zmian z repozytorium SVN:

    git svn fetch codetitans

    (za pierwszym razem pobrane zostanie pełna historia, co może trochę trwać; dla oszczędzenia czasu plecam dodanie opcji “-r <rev>” z numerem ostatniej rewizji, która jest dla nas istotna; później już oczywiście tylko ostatnie zmiany będą synchronizowane)
  4. Poprzednie polecenie, de facto, pobiera pliki, ale nie są one jeszcze nigdzie widoczne. Aby stały się widoczne, musimy połączyć je (operacją merge) z aktualnym branchem (tym utworzonym i ustawionym jako aktualny w kroku 1.).
    Pytanie pozostaje, co mamy teraz łączyć.

    Lista wszystkich branchy (git branch –a) ujawnia, że zostało dodane wskazanie zewnętrzne na kod SVN. Wygląda ono mniej więcej tak:

    remotes/Externals/CodeTitans/git-svn

    I łączymy kod:

    git merge –squash remotes/Externals/CodeTitans/git-svn

    Uwaga! W przyszłości to właśnie tutaj, podczas operacji merge będzie występowało najwięcej konfliktów. Tutaj też ładnie je rozwiążemy, a osobny branch gwarantuje nam, że nie mieszamy kodu (i zmian w nim) projektu zewnętrznego z naszym produkcyjnym.
  5. Wprowadzamy wszystkie niezbędne poprawki (przenosimy, zmieniamy treść plików…). Oczywiście operacje te kończymy pojedynczym:

    git commit –a –m “<komunikat>
  6. Wracamy z powrotem na nasz główny branch:

    git checkout develop
  7. I dodajemy do niego wypielęgnowany kod zewnętrznego projektu, który idealnie pasuje do naszej struktury:

    git merge --no-ff codetitans_develop

    - --no-ff – bardzo ważna opcja dla późniejszej graficznej wizualizacji repozytorium i zmian na nim; otóż wszystkie zmiany z brancha codetitans_develop nie zostaną wessane do brancha aktywnego w tym momencie brancha develop

    Tutaj już nie powinny wystąpić żadne konflikty, bo kod jest jednak rozdzielny, a wszystkie zmiany odnośnie zewnętrznej biblioteki prowadzone były na branchu “codetitans_develop”.
  8. Aktualizacja:

    Kiedy nasz projekt Subversion ulegnie zmianie, musimy je mozolnie dodać na repozytorium Git. Niestety, aby wszystko pięknie działało, należy wykonać wszystkie kroki od 3-ego włącznie.

Salute!



Tyle co ukazał się upragniony przez wielu Visual Studio 2010 ServicePack 1, a już okazuję się, iż kolejność instalowania dodatków do Visual Studio ma swoje zależności.

To o czym chciałem przede wszystkim powiedzieć, to wymóg instalacji Visual Studio SDK przed zainstalowaniem SP1. Inaczej nie będzie to możliwe i instalacja się nie powiedzie z dziwnie (jak zwykle?) nic nie mówiącym komunikatem o błędzie.

Error Type: Microsoft.VisualStudio.Sdk.Setup.MissingPrerequisiteException
Error Message: You must have Microsoft Visual Studio 2010 installed on your computer before procedding.

 

Visual Studio 2010 SDK Error

Jak zatem wybrnąć z tej sytuacji (bo instalacja na maszynie wirtualnej zajęła jednak sporo czasu! i cofanie jej + ponawianie to trochę zbyt wiele)? Otóż sztuczka polega na tym, aby używając monitora rejestru zobaczyć, do czego próbuje odwołać się instalator SDK. W moim przypadku było to lokalizacja numer wersji Visual Studio Service Pack:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\10.0]
“SP” = 1

A zmieniając wartość z ‘1’ na ‘0’, oszukamy na chwilkę instalator SDK. Na koniec przywracamy ‘1’ i po sprawie.

Więcej o tym, jak znaleźć rozwiązanie samemu następnym razem - tutaj.



Czasem zdarza się sytuacja, w której ktoś, kto ma dostęp tylko do odczytu do naszego repozytorium SVN, chciałby w nim coś jednak zapisać. Udało mu się (lub jej) rozwiązać jakąś usterkę czy problem, albo usprawnić działanie. Moglibyśmy w tym miejscu dodać uprawnienia do zapisu i byłoby po sprawie.

Jednak czy na pewno? Zawsze jakieś “ale”! Z czegoś wynikał przecież fakt, że ów użytkownik nie posiadał pełni praw.

  • Czy wspomniana zmiana ma w ogóle sens i czy w ogóle istnieje? (może ktoś tylko chce wyłudzić dostęp)
  • Czy zmiany są w pełni przetestowane?
  • Czy nie wprowadzają luk w zabezpieczeniach i innych ukrytych furtek?
  • Czy zgadzają się one z konwencją nazewniczą i stosują projektowe formatowanie kodu?
  • Czy będziemy pamiętać, o cofnięciu uprawnień, gdy zmiany zostaną już wysłane do repozytorium?

Wyjściem z tej sytuacji może okazać się utworzenie "łatki" (patcha), która zawierała będzie tylko proponowane zmiany w konkretnych plikach i lokalizacjach. Później przekazanie jej zaufanej osobie w projekcie, która zmiany te może przejrzeć, ocenić i ma prawa do zapisu na serwerze. Oto jak się za to zabrać:

  1. Zapamiętanie zmian:

    svn diff > fix.diff

    (Rozszerzenie diff jest rozpoznawane przez wiele edytorów, podświetlając składnię podczas przeglądania, niemniej jednak każde inne byłoby równie dobre)

  2. Aplikacja zmian:

    patch -p0 -i fix.diff

    Teraz można sprawdzić, co i gdzie się zmieniło i po przeglądzie (oraz koniecznie testach) wysłać do repozytorium na serwerze.
  3. Wysłanie na serwer:

    svn commit –m “<message> 


Autor

Paweł Hofman [CodeTitans]

ASP.NET
C/C++, C#, Objective-C
SQL

License and Disclaimer

Moje Gry i Aplikacje

Zobacz mnie na GoldenLine

Zobacz mnie na LinkedIn
Supported by Polish SQL Server User Group (PLSSUG)

Supported by WrocNet.org

Zine.net.pl

Wpisy

Projekty

Moje projekty open-source:

Sign in