Temat: SVN - błąd w konfiguracji czy niedoróbka

Jarosław Rybski:

No pewnie tak jest - wg Ciebie. Ja uważam że to dobry styl w projekcie w którym uczestniczę. Nie rozumiem tego jak można coś takiego wywnioskować nie widząc projektu. Skoro blokowanie plików jest takie złe więc po co to zostało zaimplementowane w systemach kontroli wersji.
Każdy ma swoje zdanie i znajdą się osoby które potwierdzą że to jest im potrzebne a inni wręcz przeciwnie. Natomiast nigdy nie znalazłem osoby która by stwierdziła że coś robimy źle, niewłaściwie nie wiedząc co robimy i jak to robimy.

Ujmę to tak: można kluczem płaskim wkręcać imbusy i "gwiazdki". Można próbować wkręcać nożem... Pytanie tylko, czy po to stworzyli śruby imbusowe by tak kombinować. SVN jest po to by pobierać z repo, modyfikować lokalnie, zapisywać na serwer, to raz. Po drugie: commit/update mają być jak najkrótsze, by nie blokować repo na zbyt długo. Po trzecie: przesiadka z VSS (ze wszystkimi przyzwyczajeniami) powoduje, że migracja traci, IMO, jakikolwiek sens.

PS: Jeśli to nie tajemnica: co w projekcie jest takiego specyficznego że wymaga podejścia do Subversion w, hmmm, niekonwencjonalny sposób?

Temat: SVN - błąd w konfiguracji czy niedoróbka

SVNa można używać na kilka sposobów. Więc jak każdy się upiera o tym że
blokowanie plików jest złe to czy tej opcji by nie wyłączyli w SVN-ie?

Ponadto życzę powodzenia na projekcie gdzie trzech programistów zabrało się za
edycję i przerabiało wygląd formularza bez blokowania (borland plik dfm).

Ponadto dla przykładu jeśli masz 100 programistów i 90 opowiedziało się
za blokowaniem bo jednak bezpieczniej, 5 opowiedziało się za modyfikowaniem
lokalnie bez blokowania bo szybciej a pozostałych 5 nie miało swojego zdania to wiadomo co kierownictwo może zrobić - zróbmy tak jak programiści uznali skoro to
im pracę ułatwia, wyklucza powstawanie błędów etc.

Podam jeszcze jeden przykład - jest 100 programistów oraz jeden nadzorca
- nikt nie blokuje plików, nie wiadomo kto co już oddał, trzeba spytać każdego
po kolei czy skończył już czy nie co będzie jeszcze edytował etc. Co mu zostało ile to może potrwać. - Tu akurat może mi się źle wydawać bo dopiero się wdrażam a SVNem - ale niech będzie że się pomyliłem.

A jeśli mamy blokowanie plików i 5 programistów z tej setki nie oddało źródeł to
pytamy tylko tych pięciu kiedy kończą, ile pozostało ...

VSS był bardzo fajny - widziałem kto co robi, wiedziałem kiedy mogę wejść
komuś w paradę itp.

Co sie robi na projekcie to wiesz - TAJEMNICA ZAWODOWA ZOOBOWIAZUJE.

Bylem na projekcie gdzie pracowało dużo ludzi, bardzo dużo i wyobraź sobie
że mieliśmy blokowanie plików na wyłączność ale to już na całkiem innym systemie kontroli wersji. Ale jeśli na pierwszym miejscu
kładzie się nacisk na bezpieczeństwo oraz poprawne działanie wg założeń projektowych gdzie bardzo łatwo o pomyłkę ze względu na merytorykę, a w drugiej kolejności na szybkość wytwarzania projektu to tak to jest.

Wy piszecie że blokowanie jest złe dlatego że gonicie, prędzej, szybciej a to że są błędy to trudno - no ale i u mnie tez gonimy:-). Na koniec dnia wypadało by coś do repozytorium oddać.
Owszem można tak i tak - coś kosztem czegoś a to zależy już od polityki zarządzania projektem, systemu zarządzania jakością, wypracowanych standardów i wielu innych wytycznych a jak wiadomo nie każdy projekt jest taki sam i wymaga stosowania tych samych narzędzi, standardów....

Reasumując - wątek zamykamy, ktoś kto wie tylko swoje i nie uznaje opinii innych będzie wiedział tylko swoje.
I nie piszcie że robię coś źle - jestem tylko programistą, i nie zapominajcie się - nie piszcie o teleskopach i młotkach bo pytałem tylko o ikonki, nie pytałem czy blokować pliki i jakie są tego wady a jakie zalety.
Pozdrawiam.

Temat: SVN - błąd w konfiguracji czy niedoróbka

Nie piszę że ktoś coś źle ;) Warto mieć na uwadze, że to grupa dyskusyjna i pojawiają się wątki poboczne, nie zawsze mające wiele wspólnego z głównym wątkiem ;>

1. Problem ikonek w kliencie SVN - zgłoś do developerów ulubionego klienta SVN. Prawdopodobnie mają jakiś issue tracker, w którym być może ktoś kiedyś już zgłaszał podobny problem. (Wcześniej pisałem mylnie o developerach SVN, mea culpa.)

2. Lockowanie plików - użyteczna funkcjonalność, jednak może być nadużywana. Jeśli chodzi o mnie, to najlepiej sprawdza się w przypadku mergowania zmian ze snapshota do określonej gałęzi kodu.

3. (Dez)organizacja pracy

[cytat]
Podam jeszcze jeden przykład - jest 100 programistów oraz jeden nadzorca
- nikt nie blokuje plików, nie wiadomo kto co już oddał, trzeba spytać każdego
po kolei czy skończył już czy nie co będzie jeszcze edytował etc. Co mu zostało ile to może potrwać. - Tu akurat może mi się źle wydawać bo dopiero się wdrażam a SVNem - ale niech będzie że się pomyliłem.
[/cytat]

Podałeś świetny przykład na to jak jak brak "uprocesowienia" rozwoju oprogramowania generuję masę pytań i problemów. Oczywiście nie każda organizacja jest na tyle dojrzała by posiadać takie procesy. Jednak jest kilka pytań, na które można uzyskać odpowiedzi przez odpowiednie zorganizowanie pracy i produkowanie (oprócz kodu) dodatkowych "artefaktów". Myślę, że przy takiej ilości programistów warto pracę podzielić na obszary funkcjonalne, wprowadzić odpowiednią liczbę gałęzi, wyznaczyć osoby/role odpowiedzialne za mergowanie owych gałęzi i przede wszystkim zaplanować pracę, a nie tak że każdy wprowadza zmiany jak mu się podoba i kiedy mu się podoba.

pozdr,
Paweł

Temat: SVN - błąd w konfiguracji czy niedoróbka

Jarosław Rybski:
SVNa można używać na kilka sposobów. Więc jak każdy się upiera o tym że
blokowanie plików jest złe to czy tej opcji by nie wyłączyli w SVN-ie?

Ponadto życzę powodzenia na projekcie gdzie trzech programistów zabrało się za
edycję i przerabiało wygląd formularza bez blokowania (borland plik dfm).

Ponadto dla przykładu jeśli masz 100 programistów i 90 opowiedziało się
za blokowaniem bo jednak bezpieczniej, 5 opowiedziało się za modyfikowaniem
lokalnie bez blokowania bo szybciej a pozostałych 5 nie miało swojego zdania to wiadomo co kierownictwo może zrobić - zróbmy tak jak programiści uznali skoro to
im pracę ułatwia, wyklucza powstawanie błędów etc.

Podam jeszcze jeden przykład - jest 100 programistów oraz jeden nadzorca
- nikt nie blokuje plików, nie wiadomo kto co już oddał, trzeba spytać każdego
po kolei czy skończył już czy nie co będzie jeszcze edytował etc. Co mu zostało ile to może potrwać. - Tu akurat może mi się źle wydawać bo dopiero się wdrażam a SVNem - ale niech będzie że się pomyliłem.

A jeśli mamy blokowanie plików i 5 programistów z tej setki nie oddało źródeł to
pytamy tylko tych pięciu kiedy kończą, ile pozostało ...

VSS był bardzo fajny - widziałem kto co robi, wiedziałem kiedy mogę wejść
komuś w paradę itp.

Co sie robi na projekcie to wiesz - TAJEMNICA ZAWODOWA ZOOBOWIAZUJE.

Bylem na projekcie gdzie pracowało dużo ludzi, bardzo dużo i wyobraź sobie
że mieliśmy blokowanie plików na wyłączność ale to już na całkiem innym systemie kontroli wersji. Ale jeśli na pierwszym miejscu
kładzie się nacisk na bezpieczeństwo oraz poprawne działanie wg założeń projektowych gdzie bardzo łatwo o pomyłkę ze względu na merytorykę, a w drugiej kolejności na szybkość wytwarzania projektu to tak to jest.

Wy piszecie że blokowanie jest złe dlatego że gonicie, prędzej, szybciej a to że są błędy to trudno - no ale i u mnie tez gonimy:-). Na koniec dnia wypadało by coś do repozytorium oddać.
Owszem można tak i tak - coś kosztem czegoś a to zależy już od polityki zarządzania projektem, systemu zarządzania jakością, wypracowanych standardów i wielu innych wytycznych a jak wiadomo nie każdy projekt jest taki sam i wymaga stosowania tych samych narzędzi, standardów....

Reasumując - wątek zamykamy, ktoś kto wie tylko swoje i nie uznaje opinii innych będzie wiedział tylko swoje.
I nie piszcie że robię coś źle - jestem tylko programistą, i nie zapominajcie się - nie piszcie o teleskopach i młotkach bo pytałem tylko o ikonki, nie pytałem czy blokować pliki i jakie są tego wady a jakie zalety.
Pozdrawiam.

Jarosławie,

Najwięcej odpowiedzi na Twoje pytania jest w jednym miejscu:
http://svnbook.red-bean.com/

(link ten został mi polecony w chwili rekrutacji do firmy, dla której pracowałem kiedyś, gdzie ok. 10 programistów pracowało na wspólnym kodzie, żaden nie blokował jeden drugiego, każdy miał podgląd do zmian, porównania z repo).

WYdaje mi się, że niedopuszczalnym jest fakt, że "pięciu programistów uważa że formularz powinien wyglądać tak, a pozostałych pięciu uważa że inaczej". Na etapie analizy takie rzeczy również powinny być przemyślane (proszę, popraw mnie jeśli się mylę). Myślę, że teraz bardziej rozumiem co masz na myśli, ale nadal upieram się, że blokowanie plików na wyłączność nie jest najlepszym sposobem.

Temat: SVN - błąd w konfiguracji czy niedoróbka

Jarosław Rybski:
SVNa można używać na kilka sposobów. Więc jak każdy się upiera o tym że
blokowanie plików jest złe to czy tej opcji by nie wyłączyli w SVN-ie?

Złe samo w sobie to jest jak M-16 albo AK, albo maczeta albo młotek czy też mikroskop.
Po prostu nadużywane może spowodować że praca zamiast równoległa będzie szeregowa - zalokowany plik uniemożliwia komuś innemu dostarczenie nowej jego wersji, czyli jak wpadają dwa różne bugi, dotyczące różnych części pliku, do czasu rozwiązania pierwszego buga (w kolejności zalokowania) drugi nie może zostać rozwiązany.

Ponadto życzę powodzenia na projekcie gdzie trzech programistów zabrało się za
edycję i przerabiało wygląd formularza bez blokowania (borland plik dfm).

No i? KDiff3 jest, vim diff jest i kilka innych.
Ten dfm to była binarka czy tekst? Jak binarka, to samiście sobie winni, jak tekst to nie powinno być tragedii.

Ponadto dla przykładu jeśli masz 100 programistów i 90 opowiedziało się
za blokowaniem bo jednak bezpieczniej, 5 opowiedziało się za modyfikowaniem
lokalnie bez blokowania bo szybciej a pozostałych 5 nie miało swojego zdania to wiadomo co kierownictwo może zrobić - zróbmy tak jak programiści uznali skoro to
im pracę ułatwia, wyklucza powstawanie błędów etc.

Wyklucza co?
Jak masz projekt na 100 programistów, to masz taką ilość kodu że prawdopodobieństwo konfliktów znacznie spada, chyba że są permanentnie spieprzone albo arcyważne kawałki nad którymi ludzie w nieskończoność będą siedzieć po kilku zamiast je przepisać.
W pierwszym przypadku locki rzeczywiście ani ziębią, ani grzeją, w drugim utrudniają robotę.

Podam jeszcze jeden przykład - jest 100 programistów oraz jeden nadzorca
- nikt nie blokuje plików, nie wiadomo kto co już oddał, trzeba spytać każdego
po kolei czy skończył już czy nie co będzie jeszcze edytował etc. Co mu zostało ile to może potrwać. - Tu akurat może mi się źle wydawać bo dopiero się wdrażam a SVNem - ale niech będzie że się pomyliłem.

To się robi inaczej - jest bugtracker, w nim są zgłoszenia błędów, jest data builda, jest określony podzbiór błędów które byłoby miło mieć do tej daty rozwiązane.
Jeżeli któryś błąd rozwiązany nie jest, to albo przesuwa się datę builda, albo przesuwa się błąd na następny build (albo siedzi po nocach).
Organizacja w repo to branch albo tagi albo jakaś kombinacja powyższych, builda robi się z plików otagowanych, bo wtedy wiadomo z czego co powstało.

A jeśli mamy blokowanie plików i 5 programistów z tej setki nie oddało źródeł to
pytamy tylko tych pięciu kiedy kończą, ile pozostało ...

Najwyraźniej przerzucacie rzeczy które powinien zapewniać bugtracker na system kontroli wersji.
To z bugtrackera powinno wynikać, co kto (jeszcze) robi, co kto skończył i takie tam, nie z kopania w repo.
Dodatkowo SVN ma gazylion różnych webowych interfejsów, stawia się taki (pewnie integracja z bugtrackerami też jest wspierana) i po kliknięciu widać postępy, commity z rozwiązanych bugów, nowych funkcjonalności itp.

Bylem na projekcie gdzie pracowało dużo ludzi, bardzo dużo i

Ile to jest dużo? :)

Reasumując - wątek zamykamy, ktoś kto wie tylko swoje i nie uznaje opinii innych będzie wiedział tylko swoje.

Pewnie że można opierać rozwój projektu na lokach w systemie kontroli wersji, ale po prostu to wygląda jak wbijanie gwoździ mikroskopem i jest dość interesującym poznanie ideolo które stoi za tym, że ktoś koniecznie musi zalokować plik.

Temat: SVN - błąd w konfiguracji czy niedoróbka

[..]

1. Problem ikonek w kliencie SVN - zgłoś do developerów ulubionego klienta SVN. Prawdopodobnie mają jakiś issue tracker,

[...]
TortoiseSVN tego nie będzie obsługiwać - jak podałem wcześniej w dokumentacji FAQ pisze dlaczego.

Temat: SVN - błąd w konfiguracji czy niedoróbka

SVNa można używać na kilka sposobów. Więc jak każdy się upiera o tym że blokowanie plików jest złe to czy tej opcji
by nie wyłączyli w SVN-ie?

W Subversion są blokady, po to by obsłużyć m. in. pliki binarne,
które z założenia stanowią nie duży wycinek projektu.

[...]

I nie piszcie że robię coś źle - jestem tylko programistą, i nie zapominajcie się - nie piszcie o teleskopach i młotkach bo pytałem tylko o ikonki, nie pytałem czy blokować pliki i jakie są tego wady a jakie zalety.

Powtórzę się, za po mocą TortoiseSVN tego nie uzyskasz (dlaczego
to odsyłać do dokumentacji). Subversion (a co za tym idzie i jego
narzędzia po stronie klienta) ma inne założenia co do stylu pracy
niż VSS.

Jeżeli nie ma możliwości zmiany organizacji pracy, to może jest
możliwość wymiany Subversion na taki, który wspiera podobny model
do VSS.

Temat: SVN - błąd w konfiguracji czy niedoróbka

[...]
Stary temat, ale może się przydać, przez przypadek znalezione:
CommitMonitor

Temat: SVN - błąd w konfiguracji czy niedoróbka

Jarosław P.:
[...]
Stary temat, ale może się przydać, przez przypadek znalezione:
CommitMonitor

Wygląda interesująca, zastanawia mnie jednak, czy nie ma czegoś działającego server-side, co generowałoby po prostu RSSa z commitow.

Temat: SVN - błąd w konfiguracji czy niedoróbka

Jakub L.:

Jarosław P.:
[...]
Stary temat, ale może się przydać, przez przypadek znalezione:
CommitMonitor

Wygląda interesująca, zastanawia mnie jednak, czy nie ma czegoś działającego server-side, co generowałoby po prostu RSSa z commitow.

Trac, Redmine ?

Temat: SVN - błąd w konfiguracji czy niedoróbka

W całej dyskuski "Jak lockować pliki w SVN? vs. Lockowanie jest złe!" ciekawi mnie jedna rzecz - dlaczego (prócz wstawki o tagowaniu na użytek releasów) nikt nie wspomniał o branchach? Dla mnie naturalne jest, że jeśli coś wymagałoby blokowania (bo np. dodanie funkcjonalności zmienia drobiazgi w wielu plikach), to robi się na użytek tego branch. Więcej - ostatnio, gdy pracowałem na SVN polityka była taka:
- wszystko na koniec dnia ma być commitowane (nie wierzymy lokalnym kopiom)
- co najmniej dwa branche (tag releasowy z ostatniego wydania i aktualny "główny" branch) muszą być zawsze kompilowalne (co kontroluje system nocnych buildów + kompilacja via post-commit co jakiś czas)
- z powyższego wynikało - jeśli robota przeciąga Ci się ponad dzień, to tworzysz branch i dbasz o jego aktualność (synchronizację z głównym deweloperskim). Na końcu dbasz o merge z głównym.

Trzy osoby biorące się jednocześnie za jeden formularz to w znanych mi przypadkach patologia, którą warto wyeliminować. Ale widziałem tylko kilka środowisk projektowych (sposobów organizacji) w życiu, daleki jestem od uogólniania.

Tak - są wyjątki, gdzie przydatne byłoby lockowanie. Osobiście spotkałem się z .vcproj (szczególnie przy "wsparciu" narzędzi Qt). Akurat w tym wypadku, żeby uniknąć kolizji dodawało się mockowe pliki na początku pracy nad zagadnieniem, żeby ograniczyć do minimum liczbę commitów zmieniających .vcproj.