Kolo 1

Debugger modyfikuje kod źródłowy programu

- FAŁSZ – nie modyfikuje tylko sprawdza

Scentralizowane systemy zarządzania wersjami (np. Subversion) oparte są na architekturze P2P

FAŁSZ – bo na klient-server / server-klient

Refactoring powoduje modyfikacje w funkcjonalności programu

- FAŁSZ – tylko eliminuje powtarzające się linijki, funkcjonalność ta sama

W systemie Subversion w wyniku wysłania nowej wersji określonego pliku do repozytorium całe repozytorium uzyskuje nowy numer rewizji

- PRAWDA - numer rewizji oznacza numer kolejnego wykonania Commita

W kodzie występuje przynajmniej jeden błąd kompilacji int tab = new int[5]; for (int i=0; i<27; i++) delete tab;

- PRAWDA - powinno być int [] tab

Błąd występujący w kodzie może ujawnić się w trakcie wykonania programu int tab = new int[25]; for (int i=0; i<27; i++) tab[i] = rand() % 100; delete tab;

PRAWDA - Wyciek pamięci ZAWSZE może ujawnić się w trakcie działania programu.Np. Gdy zabraknie Ci w końcu RAM.

Wycieki pamięci powstają w wyniku alokowania przez program zbyt małej ilości pamięci

- FAŁSZ - fałsz bo wycieki powstają kiedy nie zwalniamy pamięci

Nowy programista, który dołącza do projektu przechowywanego w repozytorium zarządzanym przez system Subversion powinien znać adres url repozytorium -

PRAWDA - jezeli nie zna to nie polaczy sie z nim

Dostęp do repozytorium zarządzanego przez Subversion nie jest możliwy z wykorzystaniem protokołu ftp -

FAŁSZ - dostęp do repozytorium jest tylko przez http i ssh

Generowanie dokumentacji technicznej projektu za pomocą Javadoc polega na przetworzeniu specjalnych komentarzy umieszczonych w kodzie Java na strony www

- PRAWDA - Wykorzystuje się do tego adnotacje w komentarzach

Scentralizowane systemy zarządzania wersjami (np. Subversion) oparte są na architekturze klient-server

-PRAWDA - bo po prostu są oparte;D

TortoiseSVN jest tekstowym klientem systemu Subversion

- FAŁSZ - bo jest graficzną nakładką

Wycieki pamięci są automatycznie naprawiane przez Valgrind

- FAŁSZ - Valgrind tylko wskaże nam wyciek

Repozytorium kodu źródłowego zarządzane przez system Subversion powinno zawierać zgodnie z zaleceniami katalog trunk przechowujący alternatywne gałęzie projektu

- FAŁSZ - przechowuje tylko wersję roboczą

Breakpoint w debugger’e oznacza miejsce rozpoczęcia wykonywania programu

- FAŁSZ - nie rozpoczęcia tylko zakończenia przebiegu

Klient Subversion może być oferowany przez środowisko programistyczne IDE

- PRAWDA - jak najbardziej, NetBeans oferuje

W systemie Git klonowanie zdalnego repozytorium powoduje powstanie pełnej kopi repozytorium na lokalnej maszynie

- PRAWDA - no tak

Repozytorium kodu źródłowego zarządzane przez system Subversion powinno zawierać zgodnie z zaleceniami katalog BRANCHES przechowujący główną linię rozwojową kodu źródłowego projektu

- FAŁSZ - Katalog branches jest na poboczne gałęzie projektu

Przykładem refectoringu kodu jest dodanie nowej metody (nowej funkcjonalności) do istniejącej klasy

- FALSZ - nie tworzy nowej funkcjonalności tylko minimalizuje powtarzające się

Sprawdzenie zawartości repozytorium zarzadzanego przez Subversion jest możliwe bez konieczności tworzenia lokalnej kopi repozytorium

- PRAWDA - tak, przez protokól SSH lub HTTP

W systemie Git operacj push służy do wysłania lokalnych zmian do zdalnej kopi repozytorium

- PRAWDA - tak sie dzieje dokładnie

Błąd występujący w kodzie zostanie wykryty przez Dr Memory

- FAŁSZ - Program się nie skompiluje, wiec nie zostanie utworzony plik wykonywalny (a Dr Memory sprawdza pliki wykonywalne)

Refaktoring powoduje zmiany w kodzie źródłowym oprogramowania

- PRAWDA - minimalizuje powtarzające się

Historia zmian w Subversion dostarcza informacji na temat kto wprowadzał zmiany w danej rewizji

- PRAWDA - można sprwdzić to w logach

Sprawdzenie zawartości repozytorium zarzadzanego przez Subversion nie jest możliwe bez konieczności tworzenia lokalnej kopi repozytorium

- FAŁSZ - bo jest możliwe przez protokół SSH lub HTTP

Nowy programista, który dołącza do projektu przechowywanego w repozytorium zarządzanym przez system Subversion może obejrzeć zawartość repozytorim w przeglądarce internetowej jeżeli dostęp do repozytorium odbywa się poprzez protokół http

- PRAWDA - przez protokół HTTP

Przykładem refectoringu kodu jest zastąpienie podobnych albo takich samych fragmentów kodu przez procedurę

- PRAWDA - dokładnie tak to działa

Wycieki pamięci zostaną wykryte podczas kompilacji kodu za pomocą kompilatora, np. g++

FAŁSZ - kompilator nie wykrywa co innego gdyby odpalić valgrind –leak

Konflikt w systemie Subversion może powstać podczas wykonywania komendy checkout

- FAŁSZ - pobiera aktualna wersja wiec chyba bez konfliktu, konflikt może być przy commit jeżeli ktoś już wcześniej zatwierdzi zanim Ty to zrobisz

Dostęp do repozytorium zarządzanego przez Subversion może odbywać się przez protokół http -

PRAWDA – i przez SSH też

W systemie Git operacja COMMIT przenosi zmiany z kopi lokalnej do zdalnego repozytorium -

PRAWDA - po to jest właśnie by przenieść dane do zdalnego repozytorium komp -> repozyrotium

Analiza programu za pomocą Dr Memory nie wymaga wcześniejszej kompilacji kodu

- FAŁSZ - Dr Memory sprwadza pliki wykonawalne, wiec musi wczesniej byc skompilowany

Valgrind nie zasygnalizuje czytania poza zakresem statycznie alokowanej tablicy

- PRAWDA - wg wykładu "valgrind nie wykrwya błędów związanych ze statycznie alokowanymi obszarami pamięci"

Jedną z możliwości debugger'a GDB jest wyświetlenie aktualnego stosu wywołań funkcji

- PRAWDA - pozwala na to komendą -bt

Środowisko wytwórcze Eclipse jest środowiskiem modułowym, rozszerzalnym poprzez plugin'y

- PRAWDA - mozna rozszerzac instalując dodatkowe pluginy

Polecenie diff w systemie Subversion pozwala na porównanie kopi lokalnej i kopi znajdującej się w repozytorium określonego pliku

- PRAWDA - tak to działa

TortoiseSVN jest graficznym klientem systemu Git

- FAŁSZ - TortoiseSVN jest gaficznym klientem SVN a nie GIT

Debugger może zostać uruchomiony mimo istnienia błędów kompilacji

- PRAWDA - po to jest

Operacja commit w systemie Subversion przenosi zmiany z repozytorium zdalnego do lokalnej kopi użytkownika

- FAŁSZ – przenosi z lokalnej do repo, komp -> repo a nie odwrotnie, do tego służy update lub /co/

Historia zmian w Subversion dostarcza informacji na temat plików zmodyfikowanych w poszczególnych rewizjach

- PRAWDA - TAK w logach

Historia zmian w Subversion dostarcza informacji na temat używanego przez użytkownika klienta SVN

- FAŁSZ - nie umieszcza takiej informacji, umieszcza jedynie datę, komentarz i co zostało zmodyfikowane