Zarządzanie różnymi wersjami skryptu Opcje

[athabus]

Witajcie.

Mam taki problem, że chciałbym zarządzać różnymi wersjami tego samego skryptu.

Dla uproszczenia powiedzmy, że mam skrypt sklepu pisany pod konkretne wymagania klienta. Chciałbym mieć "gotową" bazę i dopisywać funkcjonalności według potrzeb. Z drugiej strony wiadomo, że czasami pojawi się jakieś udoskonalenie, które chciałbym dodać do bazowej wersji skryptu.

I tu pojawia się problem jak czymś taki zarządzać? Jak się nie pogubić?

Myślę nad wykorzystaniem svn i rozwijaniem każdego "klienta" w osobnej gałęzi, ale może są jakieś lepsze pomysły na to? Czy w svn'nie nie pojawi się w końcu tyle rozbieżności, że każde łączenie będzie oznaczało godzinę ślęczenia nad rozwiązywaniem konfliktów?

Będę wdzięczny za dzielenie się swoimi doświadczeniami.

[askone]

Z własnego doświadczenia mogę powiedzieć, że prędzej czy później coś Ci się rozjedzie... Przy mniejszych projektach daje się wdrażać udoskonalenia w core systemu, ale później w miarę rozwoju pojawia się tyle zależności, że bezproblemowe ich dołączenie w różnych wersjach jest katorżniczą pracą...

Pozdro

[mike]

Zdecydowanie musisz użyć systemu kontroli wersji. W związku z tym, że nastawiasz się na sporo gałęzi i zarządzanie nimi unikaj SVN'a.
SVN ssie. Wybierz GIT'a.

[nospor]

SVN ssie.

A jakaś bardziej konkretna argumentacja? Ja tam używam do tego celu SVN i jakoś mnie nie ssie... no chyba że z głodu

[piotrooo89]

ja też SVN'a używam i pięknie wszystko mi działa... zrobię jakiś mały postęp w pisaniu aplikacji cyk commit i już mam kolejna wersje później mogę cofnąć zobaczyć co się zmieniło etc. zdecydowanie system kontroli wersji nie ssie

[scanner]

ssie, to CVS.
SVN mi się osobiście bardzo podoba - a mamy tych repozytoriów nieco - w bardzo rożny sposób zagnieżdżonych.

Mike, może rozwiniesz swoją myśl?

[darko]

Systemy kontroli wersji są bardzo dobrym rozwiązaniem, przy większych projektach najlepiej: framework, modularna (modułowa) budowa aplikacji i system kontroli wersji i chyba to byłoby najbardziej optymalne rozwiązanie (sensowne dla średnich i dużych projektów). Wtedy zarządzałbyś wersjami i wprowadzał modyfikacje do wybranych przez Ciebie modułów.

[athabus]

Systemy kontroli wersji są bardzo dobrym rozwiązaniem, przy większych projektach najlepiej: framework, modularna (modułowa) budowa aplikacji i system kontroli wersji i chyba to byłoby najbardziej optymalne rozwiązanie (sensowne dla średnich i dużych projektów). Wtedy zarządzałbyś wersjami i wprowadzał modyfikacje do wybranych przez Ciebie modułów.

W zasadzie tak to u mnie teraz wygląda. Tj. framework, MVC i SVN. Z tym, że do tej pory rozwijałem raczej projekt liniowo a teraz będę musiał rozwijać kilka wersji tego samego projektu równocześnie. Myślę nad tym jak to zrobić aby za dużo się nie narobić - boję się rozwijać przez dłuższy czas kilku gałęzi równocześnie bo po dłuższym czasie mogą pojawić się kłopoty z integracją "jądra". Niestety nic innego od gałęzi nie przychodzi mi do głowy.

[darko]

Nie mam dużego stażu w php, ale sądzę, że przy dobrze zaprojektowanych modułach aplikacji i samej aplikacji (budowa modularna, duża elastyczność, dalece idąca "konfigurowalność" etc. etc.) wspólna logika powinna być jak najbardziej odseparowana od reszty kodu (modułów). Natomiast modyfikacje/ulepszenia/udziwnienia/dodatki (o których rozmawiamy) są wprowadzane w konkretnych i w miarę samodzielnych modułach, tylko tam, gdzie rzeczywiście zachodzi taka potrzeba. Zmiany te nie mogą mieć wpływu na tzw. logikę biznesową. Wiem, że lecę ogólnikami, ale jest to jak najbardziej wykonalne, a nawet wskazane (tym bardziej we wzorcu MVC).

[mike]

Też mi się wydawało kiedyś, że SVN daje wszystko to czego potrzeba.
Okazuje się, że nie: http://whygitisbetterthanx.com

Przede wszystkim praca z wieloma gałęziami, repozytoriami, mergowaniem w GITcie jest dużo przyjemniejsza i prostsza niż w SVN.

[athabus]

Mike nawet zaciekawiłeś mnie tym git'em - jakoś wcześniej nie miałem okazji się przyjrzeć.

Powiem Ci, że masz dużo racji jeśli chodzi o pracę z gałęziami - jest o niebo lepsze niż w SVN. Praca w CLI na SVN przy gałęziach to jest masakra w porównaniu z GIT ;-) Ale w sumie jednak zostanę przy SVN - jakoś nie przemawia do mnie lokalne repozytorium - coś scentralizowanego bardziej mi odpowiada.
Druga rzecz, która rzuciła mi się w oczy to zbyt obszerne komentarze GIT'a w konsoli - za dużo czytania jak dla mnie - W SVN konsola wypluwa to co potrzeba i tylko to co potrzeba.

Muszę jednak przyznać, że kilka rozwiązań z GIT'a chętnie bym zobaczył w SVN'ie

---
*Swoją opinię piszę po ~1,5 godzin zabawy z GIT więc mogę pisać bzdury ;-)

[nospor]

Ja tam nie wiem co macie do SVN i wielu gałęzi i mergowania. Ja mam dużo tego, wszystko działa i jest GIT

[piotrooo89]

ja w svn obsługuje ok 150 plików, pisane strukturalnie i obiektowo i jeszcze nie miałem żadnego problemu po poruszaniu się po wcześniejszych wersjach

[athabus]

poruszanie się po wcześniejszych wersjach nie jest problemem, ale nie to jest istotą problemu.

Weźmy taką sytuację. Masz sklep i jego dajesz w gałęzi "trunk" - jest to czysty sklep, który rozwijasz czyli twój produkt. Do tego tworzysz wersje "na życzenie" dla klientów, które bazują na twoim sklepie, ale są jego udziwnionymi wersjami.

Rozwijasz dwie takie wersje w dwóch różnych gałęziach - dajmy s1 i s2. Czasami trafi ci się coś co chcesz z s1 przenieść do trunk, ale części rzeczy nie będziesz chciał przenosić. Poprawki z głównej gałęzi będziesz chciał również przenosić do swoich gałęzi s1 i s2 - nie będziesz przecież usuwał tego samego błędu w każdej gałęzi - git w pracy z gałęziami wydaje się być znacznie bardziej przyjazny niż svn.

Po pewnym czasie z takich projektów wychodzi mały koszmarek jeśli chodzi o zarządzanie nad którym trudno zapanować i tak się zastanawiam czy da się to na dłuższą metę ciągnąć.

[nospor]

Rozwijasz dwie takie wersje w dwóch różnych gałęziach - dajmy s1 i s2. Czasami trafi ci się coś co chcesz z s1 przenieść do trunk, ale części rzeczy nie będziesz chciał przenosić. Poprawki z głównej gałęzi będziesz chciał również przenosić do swoich gałęzi s1 i s2 - nie będziesz przecież usuwał tego samego błędu w każdej gałęzi

Ja dokładnie mam tak jak opisałeś. Mergowanie SVN sprawdza się tu bardzo dobrze.

git w pracy z gałęziami wydaje się być znacznie bardziej przyjazny niż svn

No i tu mnie masz, nie używałem GITa i nie mogę porównać. Nie mniej jednak jak pisałem wcześniej - SVN mi na tym polu sprawdza się dobrze.

[scanner]

ja w svn obsługuje ok 150 plików

Nasze repozytoria SVN zajmują mi na dysku gdzieś z 8 GB - kilkanaście repo, w jednym kilkadziesiąt gałęzi, core systemu wiązany zarówno do branchy w repo głównym jak i do repo osobnych, biblioteki trzecie typu Zend, fpdf, i wiele innych, niedawno doszła jeszcze integracja systemów z frontendami opartymi na symfony - i tak od pięciu lat
Do tego Eclipse + Subclipse + Mylyn z łączem do trac'a i nie wiem, co może być lepszego.

Powód edycji: [scanner]:

[athabus]

W takim razie chyba spróbuję takiego podejścia... najwyżej się nie uda ;-)

Tym razem jednak będę bawił się konsolą, bo przy poważniejszych operacja (właśnie na gałęziach zresztą) zdarzyło mi się, że repozytorium zostało uszkodzone przez zawieszenie się subclips'a... Nie dało się commitować mimo czyszczenia etc. Pewnie jakiś magik by to naprawił, ale mi specjalnie już wtedy na tym repo nie zależało i dałem sobie spokój.

[scanner]

Polecam: http://tortoisesvn.tigris.org/

[piotrooo89]

a ja na linuxa polecam Nautilusa który zmienił się na RabbitVCS http://code.google.com/p/nautilussvn/, używa go nasz handlowiec i działa bez zarzutu, ja osobiście wszystko w konsoli klepie więc nie mam problemu z jakimś GUI

Ten post edytował piotrooo89 27.11.2009, 08:57:45

[athabus]

Tortoise odpada bo pracuję głównie pod linuxem.

Obecnie korzystam z rapidsvn i (od kilku dni) z nautilusa - używam ich głownie do przeglądania zmian etc.
Inne operacje wykonuję głównie z konsoli.