Ankhsvn i automatyczne needs-lock
Nie wyobrażam sobie pracy bez systemu kontroli wersji. I niewielu znam ludzi zajmujących się programowaniem, którzy by SVN nie doceniali.
Jako serwera SVN używam VisualSVN – napisany pod Windowsa, banalny w obsłudze, posiada GUI.
Podstawowy kient SVN – TortoiseSVN – do wszelkich commitów z dysku, dla świetnego narzędzia DIFF.
Do Visuala natomiast niesamowita wtyczka – ankSVN – bohater dzisiejszego szybkiego wpisu. Jeśli używasz Visuala i SVN a nie używasz Ankha – robisz sobie niepotrzebną robotę ;) Polecam zapoznać się z tym rozwiązaniem, dzięki któremu oszczędzam rocznie pewnie około miliona kliknięć ;)
Sprawa, o której łatwo zapomnieć a która skutecznie potrafi popsuć nerwy: needs-lock. Dzięki temu małemu atrybutowi mamy pewność, że tylko jedna osoba w danej chwili może edytować plik. Tzn. oczywiście może “złamać” czy “skraść” locka ale zrobi to świadomie.
Wiem, że można ustawić we właściwościach projektu, by na określonych lub wszystkich typach plików sam serwer zakładał atrybut needs-lock. Nigdy jednak nie chciało mi się szukać w dokumentacji jak to zrobić :) Jest łatwiejszy sposób.
W profilu użytkownika systemu Windows znajduje się folder “Subversion” a w nim plik “config”. W Win7 jest to: “C:\Users\USERNAME\AppData\Roaming\Subversion”, w winXP analogicznie w “Documents and Settings\….\Subversion”.
W pliku tym wystarczy odkomentować linię zawierając wpis:
Linie komentowane są znakiem hasha (#)
Następnie niżej, w sekcji:
możemy już konkretnie wskazać, które pliki mają mieć zakładane automatyczne property needs-lock.
Ja ustawiam zawsze:
co nadaje wszystkim plikom ów atrybut.
Dzięki temu we wszystkich projektach, których commit będziemy wykonywać z poziomu VisualStudio pliki automatycznie będą wymagały blokowania przed rozpoczęciem pracy z nimi. Wersja dla zapominalskich – m.in. dla mnie ;)
Dodatkowo:
można ustawić we właściwościach całego folderu projektu (zakładka Subversion) property tsvn:autoprops, w wartości wpisać analogicznie:
*.*=svn:needs-lock=1
i koniecznie zaznaczyć opcję “Apply property recursively”.
Jest to właściwość samego tortoise – i działa tylko gdy wykonujemy commit przy jego użyciu.
Nie znaleziono podobnych wpisów.
Komentarze
Dodaj komentarz
Loading ...
dotnetomaniak.pl on 01.30.2010
Ankhsvn i automatyczne needs-lock : andrzej.net.pl…
Dziękujemy za publikację – Trackback z dotnetomaniak.pl…
Procent on 01.30.2010
U-la-la! I w ten sposob calkowicie pozbywamy sie jednej z glownych zalet jakie daje kontrola wersji – jednoczesnej pracy na tych samych plikach przez wiecej niz 1 osobe. Moim zdaniem lock powinno sie nakladac jedynie na pliki binarne, dla ktorych merge nie jest mozliwy. Traktowanie tak wszystkich plikow z automatu to jak nóż w oko dla pracy zespolowej i nigdy bym sie na cos takiego nie zdecydowal…
andrzej on 01.30.2010
Zależy od przyzwyczajeń :)
Ja staram się tak budować aplikacje aby można było nad różnymi warstwami / modułami pracować niezależnie.
Pewnie sporo zależy od przyzwyczajeń i organizacji pracy. W zespołach w których pracowałem do tej pory właśnie needs-locki się sprawdzały.
A jak to wygląda u Was :) ?
Procent on 01.30.2010
“Niezależna praca nad modułami” jak najbardziej – nie musi to jednak przecież oznaczać JEDNOOSOBOWEJ pracy nad modułami.
andrzej on 01.30.2010
Hmm.. pewnie masz rację. Po prostu ten model pracy zawsze się sprawdzał :) Opisanej ciekawostki można użyć do zakładania automatycznych locków na pliki binarne o których napisałeś.
Chętnie poznam sposób pracy innych z SVN :) Rozumiem, że podstawą jest równoległa praca i wykonywanie branchy / merge’y ?
Procent on 01.30.2010
Branch/merge powinien być podstawą pracy zespołowej… i wlasnie dlatego od kilku miesięcy szczerze nie znosze SVNa – on w takim trybie działa po prostu ŹLE. Rozwiązaniem tego problemu są dvcs – czyli rozproszone systemy kontroli wersji (git, mercurial, bazaar). Planuje sam pisac o tym na blogu w najblizszej przyszlosci :)
andrzej on 01.30.2010
Dla mnie właśnie branche/merge (w tortoise to jest chyba połączone) były strasznie uciążliwe… Dlatego trochę z needs-locków naturalnie powstało coś na zasadzie ticketu blokującego..
O GITcie już czytam wzmiankę któryś raz – co to za rewolucja ;) ?
Trzeba nadążać za zmianami widać… Nie tylko w technologii w jakiej się coś wytwarza ale i pokrewnych ;)