svn
5 views
Skip to first unread message
Michał Pawluk
Jul 15, 2008, 3:11:59 PM7/15/08
to linuxa...@googlegroups.com
Witam
Zainstalowałem plugin svn do eclipsa i trochę się pobawiłem.
Pierwszy raz korzystam z kontroli wersji i nie do końca wiem czy dobrze
kombinuje.
Ściągnąłem pliki z repozytorium, zmodyfikowałem lokalnie plik
Testowa.java, użyłem commit dodałem komentarz i zatwierdziłem.
W svn pojawiła się nowa wersja pliku.
Następnie zmiany chciałem cofnąć.
użyłem lokalnie opcji merge i ustawiłem z wersji 9 na 2 czyli z bieżącej
na taka jaka była przed edycją.
Lokalnie wyświetliło mi się tak jak chciałem, czyli bez komentarza i
pojawiła się 10 przy nazwie pliku.
Dałem commit aby ta zmiana została zatwierdzona w svn.
Commit przeszło a jak sie przełączam na swn tam jest wersjia 9, przy
folderze src pojawiło się -1 a jak otwieram plik to jest taki jak miał być.
Jak daje w repozytorium na tym pliku - pokarz historie, to pokazuje mi 3
zmiany, ostatnia to ta wersja 10, ale wersja 9 ma gwiazdkę - coś to
chyba oznacza.
Coś tu, zdaje się, pochrzaniłem. Może ktoś z Was będzie w stanie mi w
skrócie wyjaśnić co źle zrobiłem?
pozdrawiam, michał
Robert Sajdok
Jul 15, 2008, 3:23:40 PM7/15/08
to linuxa...@googlegroups.com
Witam,
Osobiście SVN nie używałem, bo w pracy pracuje na VS, jednak zasada działania jest ta sama, z tym, że SVN ma większe możliwości. Według mnie wszystko jest w porządku. Była wersja moja, ty zablokowałeś plik, więc nikt nie mógł go edytować, zrobiłeś commita, więc opublikowałeś zmiany, plik staje się dostępny dla innych. Znowu zrobiłeś blokadę pliku i wprowadziłeś poprawki, usuwając to co zrobiłeś wcześniej, poczym wysłałeś na serwer. Wszysto się zgadza w historii repozytorium są trzy zmiany. Jedna moja i dwie twoje.
Osobiście SVN nie używałem, bo w pracy pracuje na VS, jednak zasada działania jest ta sama, z tym, że SVN ma większe możliwości. Według mnie wszystko jest w porządku. Była wersja moja, ty zablokowałeś plik, więc nikt nie mógł go edytować, zrobiłeś commita, więc opublikowałeś zmiany, plik staje się dostępny dla innych. Znowu zrobiłeś blokadę pliku i wprowadziłeś poprawki, usuwając to co zrobiłeś wcześniej, poczym wysłałeś na serwer. Wszysto się zgadza w historii repozytorium są trzy zmiany. Jedna moja i dwie twoje.
2008/7/15 Michał Pawluk <quen...@poczta.onet.pl>:
--
Robert Sajdok (Ris)
Robert Sajdok
Jul 16, 2008, 10:55:33 AM7/16/08
to linuxa...@googlegroups.com
Witam,
Dziś trochę testowałem SVN z Eclipsa. Doszedłem do tego, że dwie osoby mogą w tym samym czasie edytować ten sam plik. Jakie z tego mogą wystąpić komplikacje pozostawiam waszej wyobraźni :) Nie znam się na SVN, zwróciłem jednak uwagę, że jest coś takiego jak Lock, może to blokuje plik. Jednak jak próbuje zrobić lock na pliku, dostaje komunikat:
Some of selected resources were not locked.
svn: Locking feature temporarily disabled.
svn: Lock request failed: 500 Internal Server Error (https://linuxadvices.googlecode.com)
Ktoś ma wiedzę jak to włączyć? Jak nie to trzeba poszukać.
--
Robert Sajdok (RiS)
Dziś trochę testowałem SVN z Eclipsa. Doszedłem do tego, że dwie osoby mogą w tym samym czasie edytować ten sam plik. Jakie z tego mogą wystąpić komplikacje pozostawiam waszej wyobraźni :) Nie znam się na SVN, zwróciłem jednak uwagę, że jest coś takiego jak Lock, może to blokuje plik. Jednak jak próbuje zrobić lock na pliku, dostaje komunikat:
Some of selected resources were not locked.
svn: Locking feature temporarily disabled.
svn: Lock request failed: 500 Internal Server Error (https://linuxadvices.googlecode.com)
Ktoś ma wiedzę jak to włączyć? Jak nie to trzeba poszukać.
--
Robert Sajdok (RiS)
pikson
Jul 16, 2008, 11:08:03 AM7/16/08
to linuxa...@googlegroups.com
Po to jest svn, żeby kilka osób mogło modyfikować w tym samym czasie pliki :) Generalnie to jeśli tylko nie będzie modyfikacji tych samych linijek pliku, to proces ten jest prawie automatyczny.
Z reguły to nie potrzeba lockować plików,
W normalnym użyciu, robimy update, potem commit i w razie konflików musimy ręcznie poprawiać - synchonizować.
Pozdrawiam
Tomasz Trela
Jacek Spólnik
Jul 16, 2008, 11:10:28 AM7/16/08
to linuxa...@googlegroups.com
Mnie również się tak wydaje ;) Aczkolwiek czy to działa w rzeczywistości ? czy czasem nie trzeba jakoś svn'a googlowego dostrajać ? Wyjdzie w praniu ;)
--
Kiedy mówimy innymi językami, postrzegamy nieco inne światy ...
Kiedy mówimy innymi językami, postrzegamy nieco inne światy ...
SoNiC
Jul 16, 2008, 12:21:51 PM7/16/08
to linuxadvices
Przed commitem zawsze trzeba dac Synchronize with repository...wtedy
mamy pewność, żę zaciągnęliśmy wszystkie zmiany...potem commit :)
On 16 Lip, 17:10, "Jacek Spólnik" <jacek.spol...@gmail.com> wrote:
> Mnie również się tak wydaje ;) Aczkolwiek czy to działa w rzeczywistości ?
> czy czasem nie trzeba jakoś svn'a googlowego dostrajać ? Wyjdzie w praniu ;)
>
mamy pewność, żę zaciągnęliśmy wszystkie zmiany...potem commit :)
On 16 Lip, 17:10, "Jacek Spólnik" <jacek.spol...@gmail.com> wrote:
> Mnie również się tak wydaje ;) Aczkolwiek czy to działa w rzeczywistości ?
> czy czasem nie trzeba jakoś svn'a googlowego dostrajać ? Wyjdzie w praniu ;)
>
Robert Sajdok
Jul 16, 2008, 1:20:18 PM7/16/08
to linuxa...@googlegroups.com
Witam,
Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual Studio i tam w momencie próby edytowania pliku, kontrola wersji sprawdza, czy ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem wstanie dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje dany plik?
Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual Studio i tam w momencie próby edytowania pliku, kontrola wersji sprawdza, czy ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem wstanie dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje dany plik?
2008/7/16 pikson <pikso...@gmail.com>:
--
Robert Sajdok (Ris)
Robert Sajdok
Jul 16, 2008, 1:26:29 PM7/16/08
to linuxa...@googlegroups.com
Witam,
Jeszcze jedno, skąd mam niby wiedzieć, że nie edytuje tej samej linijki co dwie inne osoby? I jaka jest prawidłowa kolejność przy próbie edycji danej klasy. Najpierw robię zmiany potem update, na końcu commit, czy najpierw update potem zmiany na końcu commit, a kiedy synhronize?
Jeszcze jedno, skąd mam niby wiedzieć, że nie edytuje tej samej linijki co dwie inne osoby? I jaka jest prawidłowa kolejność przy próbie edycji danej klasy. Najpierw robię zmiany potem update, na końcu commit, czy najpierw update potem zmiany na końcu commit, a kiedy synhronize?
2008/7/16 pikson <pikso...@gmail.com>:
--
Robert Sajdok (Ris)
Daniel Żmuda
Jul 16, 2008, 1:36:12 PM7/16/08
to linuxa...@googlegroups.com
Hellooooo, a jak sadzisz sadzisz co bylo jednym z powodow odkrycia i
stworzenia narzedzii kontroli wersji pomijajac sama kontrole wersji ???
Wlasnie po to, aby developerzy mogli rownolegle pracowac na tych samych
plikach, a przy commicie rozwiazywac konflikty. Mozesz edytowac te same
linie i inne co najwyzej bedziesz musial recznie rozwiazac konflikt.
Szczerze mowiac jeszcze nie zdazylo mi sie podczas mojej kariery zebym
korzystal z Locka na dany zasob, a troszke juz w tym siedze.
Robert Sajdok pisze:
--
Pozdrawiam,
Daniel Żmuda
stworzenia narzedzii kontroli wersji pomijajac sama kontrole wersji ???
Wlasnie po to, aby developerzy mogli rownolegle pracowac na tych samych
plikach, a przy commicie rozwiazywac konflikty. Mozesz edytowac te same
linie i inne co najwyzej bedziesz musial recznie rozwiazac konflikt.
Szczerze mowiac jeszcze nie zdazylo mi sie podczas mojej kariery zebym
korzystal z Locka na dany zasob, a troszke juz w tym siedze.
Robert Sajdok pisze:
> Witam,
> Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual Studio
> i tam w momencie próby edytowania pliku, kontrola wersji sprawdza, czy
> ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem wstanie
> dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje dany plik?
>
> 2008/7/16 pikson <pikso...@gmail.com <mailto:pikso...@gmail.com>>:
> Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual Studio
> i tam w momencie próby edytowania pliku, kontrola wersji sprawdza, czy
> ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem wstanie
> dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje dany plik?
>
Pozdrawiam,
Daniel Żmuda
Daniel Żmuda
Jul 16, 2008, 1:37:17 PM7/16/08
to linuxa...@googlegroups.com
A pozatym mialem gdzies jakis fajny link do artykulu o korzystaniu z
takich tooli i tzw. 'grzechy glowne' jak mi sie uda go gdzies odnalezc
to dam znac i zamieszcze na wiki.
Robert Sajdok pisze:
--
Pozdrawiam,
Daniel Żmuda
takich tooli i tzw. 'grzechy glowne' jak mi sie uda go gdzies odnalezc
to dam znac i zamieszcze na wiki.
Robert Sajdok pisze:
> Witam,
> Jeszcze jedno, skąd mam niby wiedzieć, że nie edytuje tej samej linijki
> co dwie inne osoby? I jaka jest prawidłowa kolejność przy próbie edycji
> danej klasy. Najpierw robię zmiany potem update, na końcu commit, czy
> najpierw update potem zmiany na końcu commit, a kiedy synhronize?
>
> 2008/7/16 pikson <pikso...@gmail.com <mailto:pikso...@gmail.com>>:
> Jeszcze jedno, skąd mam niby wiedzieć, że nie edytuje tej samej linijki
> co dwie inne osoby? I jaka jest prawidłowa kolejność przy próbie edycji
> danej klasy. Najpierw robię zmiany potem update, na końcu commit, czy
> najpierw update potem zmiany na końcu commit, a kiedy synhronize?
>
Pozdrawiam,
Daniel Żmuda
Robert Sajdok
Jul 16, 2008, 1:43:25 PM7/16/08
to linuxa...@googlegroups.com
Witam,
Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i modyfikowały ją według własnego uznania? I niby jak każda z osobna ma decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby postanowią coś zrefaktoryzować po całym projekcie. No nic może ja tego do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę jak to sie ma potem zgrać :)
Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i modyfikowały ją według własnego uznania? I niby jak każda z osobna ma decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby postanowią coś zrefaktoryzować po całym projekcie. No nic może ja tego do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę jak to sie ma potem zgrać :)
2008/7/16 Daniel Żmuda <zmuda....@gmail.com>:
--
Robert Sajdok (Ris)
Daniel Żmuda
Jul 16, 2008, 1:45:23 PM7/16/08
to linuxa...@googlegroups.com
Wydaje mi sie, iz metodologia zarzadzania projektami w jasny sposob
okresla za co ktory developer odpowiada oraz, ktorego buga/feature ma
ogarnac. Jesli spojrzec z tej strony to kwestia edytowania tej samej
metody/czesci kodu nie jest juz tak straszna. Racja ?
Robert Sajdok pisze:
--
Pozdrawiam,
Daniel Żmuda
okresla za co ktory developer odpowiada oraz, ktorego buga/feature ma
ogarnac. Jesli spojrzec z tej strony to kwestia edytowania tej samej
metody/czesci kodu nie jest juz tak straszna. Racja ?
Robert Sajdok pisze:
> Witam,
> Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że
> jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i
> modyfikowały ją według własnego uznania? I niby jak każda z osobna ma
> decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to
> dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby
> postanowią coś zrefaktoryzować po całym projekcie. No nic może ja tego
> do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze
> rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę jak to
> sie ma potem zgrać :)
>
> 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
> <mailto:zmuda....@gmail.com>>:
> Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że
> jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i
> modyfikowały ją według własnego uznania? I niby jak każda z osobna ma
> decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to
> dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby
> postanowią coś zrefaktoryzować po całym projekcie. No nic może ja tego
> do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze
> rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę jak to
> sie ma potem zgrać :)
>
> 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
>
>
> Hellooooo, a jak sadzisz sadzisz co bylo jednym z powodow odkrycia i
> stworzenia narzedzii kontroli wersji pomijajac sama kontrole wersji ???
>
> Wlasnie po to, aby developerzy mogli rownolegle pracowac na tych samych
> plikach, a przy commicie rozwiazywac konflikty. Mozesz edytowac te same
> linie i inne co najwyzej bedziesz musial recznie rozwiazac konflikt.
>
> Szczerze mowiac jeszcze nie zdazylo mi sie podczas mojej kariery zebym
> korzystal z Locka na dany zasob, a troszke juz w tym siedze.
>
> Robert Sajdok pisze:
> > Witam,
> > Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual
> Studio
> > i tam w momencie próby edytowania pliku, kontrola wersji
> sprawdza, czy
> > ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem
> wstanie
> > dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje
> dany plik?
> >
> > 2008/7/16 pikson <pikso...@gmail.com
> <mailto:pikso...@gmail.com> <mailto:pikso...@gmail.com
>
> Hellooooo, a jak sadzisz sadzisz co bylo jednym z powodow odkrycia i
> stworzenia narzedzii kontroli wersji pomijajac sama kontrole wersji ???
>
> Wlasnie po to, aby developerzy mogli rownolegle pracowac na tych samych
> plikach, a przy commicie rozwiazywac konflikty. Mozesz edytowac te same
> linie i inne co najwyzej bedziesz musial recznie rozwiazac konflikt.
>
> Szczerze mowiac jeszcze nie zdazylo mi sie podczas mojej kariery zebym
> korzystal z Locka na dany zasob, a troszke juz w tym siedze.
>
> Robert Sajdok pisze:
> > Witam,
> > Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual
> Studio
> > i tam w momencie próby edytowania pliku, kontrola wersji
> sprawdza, czy
> > ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem
> wstanie
> > dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje
> dany plik?
> >
> > 2008/7/16 pikson <pikso...@gmail.com
Pozdrawiam,
Daniel Żmuda
Daniel Żmuda
Jul 16, 2008, 1:46:48 PM7/16/08
to linuxa...@googlegroups.com
Z drugiej strony nie zastanawialem sie nigdy jak to jest w przypadku
innych narzedzi(czyt. VS). Ale wiesz Microsoft ... ;-)
Robert Sajdok pisze:
--
Pozdrawiam,
Daniel Żmuda
innych narzedzi(czyt. VS). Ale wiesz Microsoft ... ;-)
Robert Sajdok pisze:
> Witam,
> Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że
> jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i
> modyfikowały ją według własnego uznania? I niby jak każda z osobna ma
> decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to
> dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby
> postanowią coś zrefaktoryzować po całym projekcie. No nic może ja tego
> do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze
> rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę jak to
> sie ma potem zgrać :)
>
> 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
> <mailto:zmuda....@gmail.com>>:
> Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że
> jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i
> modyfikowały ją według własnego uznania? I niby jak każda z osobna ma
> decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to
> dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby
> postanowią coś zrefaktoryzować po całym projekcie. No nic może ja tego
> do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze
> rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę jak to
> sie ma potem zgrać :)
>
> 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
>
>
> Hellooooo, a jak sadzisz sadzisz co bylo jednym z powodow odkrycia i
> stworzenia narzedzii kontroli wersji pomijajac sama kontrole wersji ???
>
> Wlasnie po to, aby developerzy mogli rownolegle pracowac na tych samych
> plikach, a przy commicie rozwiazywac konflikty. Mozesz edytowac te same
> linie i inne co najwyzej bedziesz musial recznie rozwiazac konflikt.
>
> Szczerze mowiac jeszcze nie zdazylo mi sie podczas mojej kariery zebym
> korzystal z Locka na dany zasob, a troszke juz w tym siedze.
>
> Robert Sajdok pisze:
> > Witam,
> > Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual
> Studio
> > i tam w momencie próby edytowania pliku, kontrola wersji
> sprawdza, czy
> > ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem
> wstanie
> > dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje
> dany plik?
> >
> > 2008/7/16 pikson <pikso...@gmail.com
> <mailto:pikso...@gmail.com> <mailto:pikso...@gmail.com
>
> Hellooooo, a jak sadzisz sadzisz co bylo jednym z powodow odkrycia i
> stworzenia narzedzii kontroli wersji pomijajac sama kontrole wersji ???
>
> Wlasnie po to, aby developerzy mogli rownolegle pracowac na tych samych
> plikach, a przy commicie rozwiazywac konflikty. Mozesz edytowac te same
> linie i inne co najwyzej bedziesz musial recznie rozwiazac konflikt.
>
> Szczerze mowiac jeszcze nie zdazylo mi sie podczas mojej kariery zebym
> korzystal z Locka na dany zasob, a troszke juz w tym siedze.
>
> Robert Sajdok pisze:
> > Witam,
> > Pliki i owszem ale ten sam plik? Do tej pory pracowałem z Visual
> Studio
> > i tam w momencie próby edytowania pliku, kontrola wersji
> sprawdza, czy
> > ktoś tego nie edytuje, jeśli nie to zakłada blokadę. Czy jestem
> wstanie
> > dowiedzieć się z poziomu Eclipse lub konsoli SVN, że ktoś edytuje
> dany plik?
> >
> > 2008/7/16 pikson <pikso...@gmail.com
Pozdrawiam,
Daniel Żmuda
Robert Sajdok
Jul 16, 2008, 1:48:01 PM7/16/08
to linuxa...@googlegroups.com
Witam,
Tak, patrząc z tej strony masz całkowitą rację. Czyli w poważnym projekcie ludzie są przypisani do konkretnych rzeczy i nie mogą od tak sobie zmienić. Czyli gdzieś trzeba będzie to zamieszczać za co kto jest odpowiedzialny, żeby przez przypadek nie pochlastał innej rzeczy :)
Tak, patrząc z tej strony masz całkowitą rację. Czyli w poważnym projekcie ludzie są przypisani do konkretnych rzeczy i nie mogą od tak sobie zmienić. Czyli gdzieś trzeba będzie to zamieszczać za co kto jest odpowiedzialny, żeby przez przypadek nie pochlastał innej rzeczy :)
2008/7/16 Daniel Żmuda <zmuda....@gmail.com>:
--
Robert Sajdok (Ris)
Daniel Żmuda
Jul 16, 2008, 1:52:15 PM7/16/08
to linuxa...@googlegroups.com
No oczywiscie :) Juz wczesniej z Jackiem rozwazalismy Trac-a, ale
zostalismy przy issue trackerze, ktorzy zapewnia code google. Tam
project manager bedzie mogl przydzielac najprawdopodobniej taski oraz
ludzi do poszczegolnych bugow. Postaram sie dzis wieczorkiem znalezc ten
artykul o commitowaniu zasobow, gdyz bylo tam ladnie opisane w jakis
sposob tagowac commity, aby np. takie narzedzie jak issue tracker mogl
automatycznie przydzielic wszystkie commity, ktore zostaly zrobione w
ramach danego buga/feature'u. Pozwala to w piekny sposob pozniej
zobaczyc historie pracy oraz ewentualne postepy :)
Robert Sajdok pisze:
> > <mailto:pikso...@gmail.com <mailto:pikso...@gmail.com>>>>:
--
Pozdrawiam,
Daniel Żmuda
zostalismy przy issue trackerze, ktorzy zapewnia code google. Tam
project manager bedzie mogl przydzielac najprawdopodobniej taski oraz
ludzi do poszczegolnych bugow. Postaram sie dzis wieczorkiem znalezc ten
artykul o commitowaniu zasobow, gdyz bylo tam ladnie opisane w jakis
sposob tagowac commity, aby np. takie narzedzie jak issue tracker mogl
automatycznie przydzielic wszystkie commity, ktore zostaly zrobione w
ramach danego buga/feature'u. Pozwala to w piekny sposob pozniej
zobaczyc historie pracy oraz ewentualne postepy :)
Robert Sajdok pisze:
> Witam,
> Tak, patrząc z tej strony masz całkowitą rację. Czyli w poważnym
> projekcie ludzie są przypisani do konkretnych rzeczy i nie mogą od tak
> sobie zmienić. Czyli gdzieś trzeba będzie to zamieszczać za co kto jest
> odpowiedzialny, żeby przez przypadek nie pochlastał innej rzeczy :)
>
> 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
> <mailto:zmuda....@gmail.com>>:
> Tak, patrząc z tej strony masz całkowitą rację. Czyli w poważnym
> projekcie ludzie są przypisani do konkretnych rzeczy i nie mogą od tak
> sobie zmienić. Czyli gdzieś trzeba będzie to zamieszczać za co kto jest
> odpowiedzialny, żeby przez przypadek nie pochlastał innej rzeczy :)
>
> 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
>
>
> Wydaje mi sie, iz metodologia zarzadzania projektami w jasny sposob
> okresla za co ktory developer odpowiada oraz, ktorego buga/feature ma
> ogarnac. Jesli spojrzec z tej strony to kwestia edytowania tej samej
> metody/czesci kodu nie jest juz tak straszna. Racja ?
>
> Robert Sajdok pisze:
> > Witam,
> > Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że
> > jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i
> > modyfikowały ją według własnego uznania? I niby jak każda z osobna ma
> > decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to
> > dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby
> > postanowią coś zrefaktoryzować po całym projekcie. No nic może ja
> tego
> > do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze
> > rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę
> jak to
> > sie ma potem zgrać :)
> >
> > 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
> <mailto:zmuda....@gmail.com>
> > <mailto:zmuda....@gmail.com <mailto:zmuda....@gmail.com>>>:
>
> Wydaje mi sie, iz metodologia zarzadzania projektami w jasny sposob
> okresla za co ktory developer odpowiada oraz, ktorego buga/feature ma
> ogarnac. Jesli spojrzec z tej strony to kwestia edytowania tej samej
> metody/czesci kodu nie jest juz tak straszna. Racja ?
>
> Robert Sajdok pisze:
> > Witam,
> > Ja się nie upieram tylko piszę jak pracuje się w VS, nie uważasz, że
> > jest trochę dziwne żeby 4 osoby pracowały na tej samej klasie i
> > modyfikowały ją według własnego uznania? I niby jak każda z osobna ma
> > decydować, które to zmiany są właściwe a które nie ? :) Ale dobra to
> > dziwny przypadek choć możliwe. Już nie wspomnę jak, np. dwie osoby
> > postanowią coś zrefaktoryzować po całym projekcie. No nic może ja
> tego
> > do końca nie rozumiem i mam złe przyzywczajenie z VS :) Jeszcze
> > rozumiem, że kilka osób może edytować ten sam plik ale nie wiedzę
> jak to
> > sie ma potem zgrać :)
> >
> > 2008/7/16 Daniel Żmuda <zmuda....@gmail.com
> <mailto:zmuda....@gmail.com>
Pozdrawiam,
Daniel Żmuda
Robert Sajdok
Jul 16, 2008, 2:05:25 PM7/16/08
to linuxa...@googlegroups.com
--
Robert Sajdok (Ris)
stallman
Jul 16, 2008, 3:10:17 PM7/16/08
to linuxadvices
On 16 Lip, 19:52, Daniel Żmuda <zmuda.dan...@gmail.com> wrote:
> No oczywiscie :) Juz wczesniej z Jackiem rozwazalismy Trac-a, ale
> zostalismy przy issue trackerze, ktorzy zapewnia code google. Tam
> project manager bedzie mogl przydzielac najprawdopodobniej taski oraz
> ludzi do poszczegolnych bugow.
przechowywać rozważaliście takie projekty jak Assembla, Collab.net ?
(niekomercyjne oczywiście)
W Assembla dostajecie wszystko w jednym (Traca, Wiki, SVN....)
Pozdrawiam
Robert Sajdok
Jul 16, 2008, 3:20:48 PM7/16/08
to linuxa...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages