Witajcie,

Dzisiaj chciałbym poprosić Was o wytłumaczenie jednej rzeczy w związku z svn'em A mianowicie chodzi mi o sprawę tak zwanych:

- Trunk - rozumiem, że to jest aktualna wersja nad którą pracuję
- Tags - rozumiem, że to są różne wersje programu, których już nie zmieniam
- Branches - a tutaj rozumiem, że pracuje się nad wersjami, które mogą potem jak będą gotowe trafić do tags

Czy dobrze rozumuję ?

Jeśli nie to proszę o wyjaśnienie jak to traktować.

Dodatkowo proszę o informację jak nimi zarządzać - tj. jak kopiować te dane z trunk do tags, z branches do tags itp.

Szukałem na google ale nie znalazłem informacji, które by mi to pokazały jak krowie na rowie tak bym zrozumiał.


I powiedźcie czy ten Trac jest faktycznie tak dobry i czy coś mi ułatwi w pracy ?

Z góry dziękuję za pomoc

pozdrawiam,
Łukasz

Osobiście nie używam już SVN-a (na rzecz GITa), ale z tego co wiem, to jest tak:

Branches, to różne gałęzie rozwijane równolegle
Trunk, to główna gałąź (aktualna). Odpowiednik GIT-owskiego master
Tags, nie wiem co to jest, ale wujek google (jeśli dobrze go zrozumiałem) powiedział, że to są nieaktualne (nierozwijane) gałęzie/wersje projektu

A do narzędzi typu trac się nie przekonałem, nie sądze aby pomagał w pracy. Może dlatego, że mój projekt jest dość mały, jednoosobowy

Tags - tak, czy "werje", nazwal bym to "wydania", 1.0, 1.1, etc, (wersje tlumacze nizej)

Branches - rozgalezienia programu, yh, malo ich uzywalem, ale chodzi o to zeby byly rozne wersje [powiedzmy tak jak w php, 4ka i 5tka] softu i zeby mozna commitowac w czasie ich opracowywania, bo nie mozesz/nie da sie miec roznych wersji w trunku


Jak kopiowac? Albo toolem, albo

svn cp trunk tags/release_1_0_0 # bez "/" na koncu!!!


W tracu masz tickety, zarzadzanie nimi, pluginy, powiadomianie na majla, rozniste przegladanie ticketow, i podglad kodu przez svn browser.
Jesli tak prowadzisz projekt [wiele osob w projecie, projekt calkiem duzy itd; zamiast np. listy todo.txt] to ci sie przyda.

@dr_bonzo:

dziękuję za informacje

A powiedz mi czy trac pomoże mi w tych przenosinach do tags'ów czy nie za bardzo ?

I takie jeszcze pytanie - czy mogę jakoś ustawić by dany użytkownik mógł tylko czytać/pisać powiedzmy jednego brancha - czyli de facto miał tylko dostęp do np /branches/v1.0 a nic innego nie mógł odczytać ? (pytam ponieważ jeszcze nie doszedłem w dokumentacji do tego jak to robić a przydałaby mi się taka opcja)

A może znasz jakiś dobry dostępny w sieci podręcznik z którego bym się douczył svn'a ? Na razie projekt jednoosobowo będę robił ... ale podejrzewam, że prędzej czy później się rozrośnie.

pozdrawiam,
Łukasz

Jeśli chodzi o SVN to trac nic nie ma z nim wspólnego. To jest "tępe" narzędzie, które tylko wyświetla informacje pobrane z SVN'a.
Ma na celu pokazywanie repozytorium, gałęzi, plików, pokazywanie różnic pomiędzy wersjami, etc. Nie da się za jego pomocą manipulować repozytorium. No chyba że pojawiły się jakieś sprytne pluginy.

Dzięki mike.

Więc na razie mogę trac'a zostawić na trochę później

Jeśli dobrze rozumiem to do robienia wersji powinienem sobie napisać jakieś skrypty albo z palca klepać polecenia svn ... a może są jakieś ciekawe narzędzia do tego ?

pozdrawiam,
Łukasz

A ty co, sadomaso?

Do eclipsa jest kilka pluginow, np. subclipse. Bardzo fajnie sie nim zarządza projektem. No i przy okazji eclipsa masz juz narzedzie do zabawy z kodem.

Poza eclipsem jest np. dla windy TurtoiseSVN

I takie pytanie co mi teraz do głowy wpadło - jakiś mądry sposób na używanie SVN z Visual Studio Microsoft'u?

pozdr.
Łukasz

Ja jeszcze wrócę do:

- Trunk - najnowasza wersja aplikacji, taka na której się po prostu pracuje
- Tags - to są konkretne realizacje, wydałeś gdzieś jakąś i tu ją umieszczasz, przydatne jak chcesz mieć te same wersje w wielu miejscach.
- Branches - to są jak już napisali rozgałęzienia, było podane PHP4/5 ale częściej jest do np. Propel 1.2, Prolepl 1.3, czyli wersje różniące się interfejsem. W branches się zmieniają, to tu wgrywasz łatki, dodajesz nową funkcjonalność (ale taką która nie zmienia aktualnie istniejącej wersji), czyli jak ktoś korzysta z Twojej aplikacji to z tego zasysa źródła, bo tu znajdzie poprawki, usprawnienia itp. w odróżnieniu od Trunk, jest pewne że jak ściągnie najnowszą wersję wszystko będzie działać po staremu, a może nawet lepiej.

Co do Trac, to on umożliwia przeglądani źródeł, ale ważną rzeczą jest Ticket, jeśli nie najważniejszą, oraz wiki. Ogólnie tam umieszczasz dokumentacje projektu, właśnie po to jest wiki. A ticket, to po prostu rozpisujesz zadania co masz zrobić (task), co dodać/usprawnić (enhancement), czy też zgłaszane/znalezione błędy (defect). Dzięki Trac możesz przypisać takie zadanie danej grupie osób, przypisać do konkretnej "odbijać" je, jeśli coś jest nie tak, czy też dyskusja na ich temat, i to wszystko jest logowane, więc można sprawdzić co był i jak.
Do tego dzięki Mylyn (dodatek do Eclipse) to zyskuje nowy wymiar, co prawda nie ma integracji z PDT ale ma z Subclipse czy Subversive...

Co do Visual Studio http://ankhsvn.open.collab.net/

EDIT:
A co do przenoszenia zmian z trunk do branch używa się najczęściej merge, do tagów jest komenda aby je utworzyć. Są jeszcze patch'e ale to już się nie rozpisuję.

@Sędziwoj: A jeśli mam aplikację i chcę jednocześnie rozwijać gałąź 1.x i 2.x to w branches je rozwijam i jak coś będzie gotowe to wrzucam do tags ? Czy może źle rozumuje. Czy mam jakoś w trunku naraz grzebać w tych dwóch gałęziach ?

Dzięki za link do tego pluginu - jestem bardziej niż wdzięczny

A ten Mylyn to co on daje ? (wybacz, że pytam po prostu wolę od kogoś kto używa się dowiedzieć niż tylko przeczytać doc'a )

pozdrawiam,
Łukasz

Jak masz kilka brenchy 1.2, 1.3 to tagi tez masz do nich osobne 1.2.1, 1.2.2, 1.3.3 itd

To wiem ale zmiany wprowadzam normalnie w branches ? i dopiero kiedy zmiany w pełni działają wystawiam nową wersję do tags ... więc w sumie udostępniać publicznie tylko tags należy (chyba, że ktoś chce testować) mam racje ?

pozdr.
Łukasz

Pobaw sie tym: VisualSVN Server. To taki Krasnal. Mozesz wyklikac sobie wszystko, o czym wspominales (prawa do katalogow, uzytkownicy itd.).

- trunk - najbardziej aktualna, dzialajaca i sprawdzona wersja oprogramowania
- tags - wersje produkcyjne - o tyle wazne, ze masz zawsze oznaczone to, co otrzymal klient
- branches - wykorzystuje wtedy, gdy chce zrefaktoryzowac/ulepszyc jakis kawalek oprogramowania wiedzac, ze byc moze nie zdaze sie z tym uporac do wydania jakiejs wersji produkcyjnej; wowczas robie sobie galaz, w miedzyczasie dokonuje normalnie poprawek na trunku. jesli skoncze prace na galezi i efekt jest zadowalajacy, to robie merge do trunk (jesli wszystko ladnie dziala, to robie taga i oddaje klientowi). nastepnie usuwam galaz i tak w kolko.

@wolan
Zależy jak traktujesz branch, bo to zależy od konwencji. Bo można robić też tak że każda osoba ma swój i tylko merge na główne idzie.
Ale widzę że Propel 1.3, jest tak prowadzony jak mówisz. Ogólnie sam szukałem kiedyś o tym jak prowadzić takie repozytoria informacji, ale nic ciekawego nie znalazłem.

Hmm znalazłem coś takiego:

http://svnbook.red-bean.com/nightly/en/svn-book.html

Wygląda na całkiem dobrze napisaną - w każdym bądź razie trochę się z niej już nauczyłem a teraz ją drukuję

pozdrawiam,
Łukasz

@Sedziwoj
Opisalem sposob, jaki mi najbardziej pasuje. O ile rozumiem supportowanie starszych wersji kodu w branch/tags w projektach, w ktorych to konieczne, to nie podoba mi sie przypadek, gdy kazdy programista w zespole dzierga gdzies sobie na boku na swojej galezi i pozniej wrzuca to do trunk. Szczegolnie, gdy jest to ktos malo doswiadczony. Lepiej miec wszystko w trunk, aby moc w miare wczesnie reagowac na zmiany kodu zrodlowego (chwalic rowniez!). Rowniez nalezy zalozyc, ze commity sa robione regularnie. Zupelnie nie wyobrazam sobie pracy, gdy ktos trzyma kod w swojej galezi przez kilka tygodni (!).

Dodatkowo mozna w latwy sposob uzyc np. dyscyplinujacego Scmbug (integrowalem nim ostatnio bugzille i wlasnie svna), jakis build server itd.

A właśnie pytanie - nad projektem pracuje X osób jak często według Was powinny commity tego co zrobiły dawać ?

Czym jest tem scmbug ? Czy trac nie pełni takiej samej roli ?

pozdr.
Łukasz

Ja mam taką zasadę - jedna KONKRETNA (czyli nie dwie linijki, a powiedzmy 50 zmienionych, czy 300) zmiana - jeden commit. Staram się nigdy nie pakować zmian dotyczących kilku niezwiązanych ze sobą rzeczy do jednego commita.

Czyli:
- poprawiam buga - commit
- dodaję małą funkcję - commit
- dodaję część dużej funkcji - commit

A więc - rozpisuję sobie co mam zrobić na listę todo, staram się rozpisać w miarę na małe kawałki a potem po kolei robię i po każdym wykonanym (lub w trakcie jeśli jest duży a jego fragment zrobiłem) commit - czy dobrze myślę ?

pozdrawiam,
Łukasz

@Kocurro
Wg mnie programista w zespole powinien robic commita wowczas, gdy poprawil _calego_ buga lub dodal jakis _caly_ feature. Czesto spotykam sie z tym, ze programista robi commita, jak idzie do domu (nie sprawdzi, czy to co zrobil do tej pory dziala). Na szczescie nie w moim zespole.

Jesli chodzi o Scmbuga. Sluzy on do integracji systemow zglaszania bledow z systemem kontroli wersji. Glowna zaleta takiego rozwiazania jest fakt, iz do numerku bledu masz dostep z poziomu logu commita, a z poziomu bledu masz dostep do listy plikow, ktore poprawil programista. Dodatkowo mozna wymusic, aby programista dodawal komentarze w logu (z wlasnego doswiadczenia wiem, ze to niezwykle trudno przychodzi), nie poprawial cudzych bledow, zachowywal cykl zycia bledu, mozna narzucic nazewnictwo branchy i tagow itd. Wiecej znajdziesz w dokumentacji.

Trac to jest wlasnie system zglaszania bledow. Scmbuga uzywam z Subversion i Bugzilla.

@wolan
Co do komentarzy w Commit i odnośnika do ticket'u to właśnie daje Mylyn z połączeniu Trac czy Bugzilla.

Co do osobnych Branch dla programistów, to merge robi "osobnik nad nimi", który sprawdzi czy jest ok, i wtedy dopiero to zrobi. To jest jeden ze sposobów prowadzenia, mi się wydaje że lepszy jest jak każdy programista wysyła zmiany tam gdzie trzeba, a na nim leży odpowiedzialność, aby to działało.

Tak jak mówicie, commit najlepiej robić jak się skończy konkretne zadanie i ma się pewność że działa.

P.S. może kogoś zainteresuje http://blog.mwojcik.pl/2008/05/31/synchron...vn-w-subclipse/

[OT]

Znaleźliśmy błąd w systemie łączenia postów

Na maila dostałem prawidłowy link: http://blog.mwojcik.pl/2008/05/31/synchron...vn-w-subclipse/


W poście pojawił się link (po połączeniu): http://blog.mwojcik.pl/2008/05/31/synchron...vn-w-subclipse/

Wnioskuję, że to wina mechanizmu łączącego posty - zwłaszcza, że w moim odczuciu linki podane przeze mnie (a dokładniej pierwszy z nich) są poprawne

[/OT]

A teraz poczytam co przysłaliście za informacje

pozdrawiam,
Łukasz

@Sedziwoj
Pobieżnie przejrzałem stronę Mylyna i wygląda mi on na nakładkę na Eclipsa. Wymusza to jednak, aby każdy członek zespołu używał tego narzędzia. A co w przypadku, gdy ktoś chce zrobić commita z linii komend albo z TortoiseSVN? Scmbug instaluje się w hookach repozytorium, więc nie ma różnicy, skąd aktualizujesz repozytorium - zawsze pilnowane są reguły, które ustawisz.

Jeśli chodzi o pracę z repozytorium w taki sposób, jak piszesz, to mam spore wątpliwości. A to dlatego, że na pewno mniej będziesz miał konfliktów, jeśli dasz od razu commita do trunk po poprawce/dodaniu jakiegoś ficzera, niż przy merge z trunk gałęzi, która była dziergana gdzieś na boku przez dłuższy czas. Takim projektem musi zarządzać spory magik, aby porozdzielać rozłączne zadania (na innych kawałkach kodu) i jeszcze w miarę krótkie. Inaczej bałagan będzie i tyle.

Masz rację co do wymagań, że trzeba korzystać z Eclipse i tego plugin'a, ale jak pracuje grupa osób to chyba ktoś ustala co i jak ma być robione, jak ktoś nie umie się przystosować, no to sorry, ale nie nadaje się do pracy w grupie.
Do tego z tego co widzę Scmbug da się zintegrować i z SVN i Trac, więc łącząc oba zyskuje się o wiele więcej.


To było czyste rozważanie, nie twierdzę że dobre, a teraz raczej nie będę wspierał tego. Trzeba widzieć błędne poglądy, a to chyba był jeden z nich, to co podałeś wydaje się rozsądniejsze