>> >> Czy jako początkujący, zrobi mi różnicę, jeśli zainteresuję się >> >> rozproszonym >> >> Mercurial'em zamiast serwerowym Subversion? Niby jednostkę jako serwer >> >> mam do dyspozycji i nie pytam tutaj 'który z w/w jest lepszy'.
>> > Teraz "na topie" jest svn., ale niedlugo moze to byc, ktorys z >> > rozproszonych sytemow wersji.
> Czasami odnoszę wrażenie że nie wszyscy czytają to co napisali przed > wysłaniem, a ilość przedkładają nad jakość. Obym się mylił.
No, jak pisałem, długie listy pryszczerskich projektów. Przecież to wszystko są projekty Open Source. I owszem, w przypadku takich projektów to ma sens. Nie bardzo widzę sens, żeby firma robiąca komercyjne, zamknięte aplikacje używała rozproszonego VCS. Ba, powiedziałbym wręcz, że widzę sens w tym, aby nie używała rozproszonego.
On 2008-05-01, citizen hubert depesz lubaczewski testified:
> Dnia 30.04.2008 Wojciech Malinowski <vir...@wp.pl> napisał/a: >> Jedyną zaletą jest tworzenie swoich prywatnych commitów, ale w SVN też >> można mieć prywatne gałęzie, a przynajmniej wszystko jest zawsze >> backupowane na centralnym serwerze.
> zaletą jest szybkość. > do zdalnego repozytorium nigdy nie będziesz miał tak szybkiego dostępu > jak do lokalnego.
Może jak się robi edycję grafiki czy coś w ten deseń, to to ma jakiekolwiek znaczenie. W przypadku kodu źródłowego nie ma żadnego. Zmiany będą miały nie więcej niż kilka KB i to przed kompresją. Więc będzie działać szybko, nawet jeśli używasz modemu 14,4kbps ;-P
On 2008-05-01, citizen Radomir 'The Sheep' Dopieralski testified:
> Dziwne sa te uwagi, widze ze kolega raczej rozproszonego systemu nigdy > na serio nie uzywal. Po pierwsze, 3 sekundy robia gigantyczna roznice > w stylu pracy: przestaje to byc jeden commit dziennie, commitujesz > praktycznie kazda spojna zmiane, przy okazji przed commitem oczywiscie > testujesz, wiec duzo drobniejsze zmiany per commit i duzo latwiej Ci > sie potem na przyklad wycofac z czegos.
Branches w SVN to twoim zdaniem do czego służy?
> Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich calkowicie > prywatnych klonow repozytorium, ktorych nikt nigdy nie musi ogladac i na > ktorych mozesz eksperymentowac ile dusza zapragnie bez zadnego wstydu.
Możesz mieć swój prywatny branch.
> Do tego zrobienie nowego to jest mgnienie oka, a nie uzeranie sie > z firmowymi adminami.
Do zrobienia brancha w SVN trzeba firmowego admina?
> Po trzecie, nie ogladasz diffow z kazdego commita i nie zbierasz ich > z roznych maszyn -- nie wiem skad ten pomysl. Rozproszone repozytoria maja > za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na synchronizacje > dwoch repozytoriow -- najczesciej Twojego lokalnego i centralnego, > firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy > maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego > commita).
Super. A gdzie jest *centralny* backup tego wszystkiego?
Dnia 28-04-2008 o 15:36:32 Sulsa <su...@dontmail.me> napisał(a):
> 50% tych funkcji, a tu masz odpowiedz dlaczego(pod nia jest dalszy > ciag posta):
>>>> l = [dict, list, map, str, float] >>>> dir(l)
Co wy chcecie? len(dir((dict,list,map,str,float))) to w sumie tylko 27 metod. Pikuś. Sama klasa String w Ruby ma ich 77. A podobna lista, (Array.methods + Hash.methods + String.methods + Numeric.methods + Float.methods).size to 387 metod. Nie wiecie, co to jest dużo. Rozpieścił was Python swym minimalizmem. :-D
> Dla projektów nie-opensource systemy rozproszone nie mają żadnego sensu > chyba, że wprowadza je firma, która "pozwala" zabrać pracę na weekend do > domu
Nie rozumiem jaki byłby sens zabraniać czegoś takiego. W ogłoszeniu napisałem o tym że można pracować częściowo zdalnie - w tym momencie rozproszone repo nabiera ogromnego znaczenia.
> Zabezpieczen nie ma, ale ma roznice owych "3 sekund" (czy ile tam to trwa) > i koniecznosci dostepu do sieci. To jest naprawde gigantyczna roznica z > psychologicznego punktu widzenia -- a to wlasnie takie roznice zmieniaja > styl pracy.
Popieram Radomira w całej rozciągłości - ale zmiana nastawienia to nie jedyna rzecz. Rozproszone repo jest konieczne jeśli pracujemy trochę w domu, trochę w podróży, w pociągu, w samolocie, na uczelni, na wyjeździe. Słowem - tam, gdzie akurat wylądujemy z laptopem. Warto wspomnieć, że nie każdy ma dostęp do sieci w domu i wtedy można robić commita jak przyjdzie na to ochota, a pusha np. na rynku głównym albo w jakimś lokalu, przy browarku :)
Patryk Szymczak wrote: >> Dla projektów nie-opensource systemy rozproszone nie mają żadnego sensu >> chyba, że wprowadza je firma, która "pozwala" zabrać pracę na weekend do >> domu
> Nie rozumiem jaki byłby sens zabraniać czegoś takiego.
W imię braku problemów po wycieku kodu, kradzieży laptopa, itd...
Patryk Szymczak wrote: >> Dla projektów nie-opensource systemy rozproszone nie mają żadnego sensu >> chyba, że wprowadza je firma, która "pozwala" zabrać pracę na weekend do >> domu
> Nie rozumiem jaki byłby sens zabraniać czegoś takiego. W ogłoszeniu > napisałem o tym że można pracować częściowo zdalnie - w tym momencie > rozproszone repo nabiera ogromnego znaczenia.
Zauważ, że napisałem pozwala w cudzysłowie. Nie wszystkim podoba się wymuszanie zabierania pracy do domu.
Jeśli w czasie wolnym odpoczywasz (ładujesz akumulatory) to nie interesują Cię żadne rozproszone systemy kontroli wersji. A na rynek główny, czy na piwo (tak jak napisałeś w innym poście) zabierasz kobietę, a nie laptopa z projektem, nad którym pracujesz.
Bart Ogryczak wrote: >>> Rozproszone mają sens tylko dla pryszczerskich projektów.
>> Takich jak jądro Linuksa, Netbeans czy sunowska Java? :)
> Dokładnie.
AeLizm. Jak JVM Suna jest pryszczerskim projektem, to wszystko poza sterowaniem Boeingiem 777, elektorwnią atomową czy systemem antyrakietowym jest pryszczerskim projektem.
Rozproszone mają po prostu sens dla projektów developowanych "rozproszenie" co nie ma nic do pryszczerstwa. Ale tam gdzie chodzi się do pracy i commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a straty są istotne (nadużywanie branchów i wynikające z tego zdarzające się od czasu do czasu błędy merdżowania, utrata istotnych danych bo pudełko pod biurkiem zdechło, itp).
pzdr \SK -- "Never underestimate the power of human stupidity" -- L. Lang
>>> Dziwne sa te uwagi, widze ze kolega raczej rozproszonego systemu nigdy >>> na serio nie uzywal. Po pierwsze, 3 sekundy robia gigantyczna roznice >>> w stylu pracy: przestaje to byc jeden commit dziennie, commitujesz >>> praktycznie kazda spojna zmiane, przy okazji przed commitem oczywiscie >>> testujesz, wiec duzo drobniejsze zmiany per commit i duzo latwiej Ci >>> sie potem na przyklad wycofac z czegos. >> No tak. Zapomniałem, że SVN ma wbudowane zabezpieczenia przed więcej niż >> jednym commitem na dzień.
> Zabezpieczen nie ma, ale ma roznice owych "3 sekund" (czy ile tam to trwa) > i koniecznosci dostepu do sieci. To jest naprawde gigantyczna roznica z > psychologicznego punktu widzenia -- a to wlasnie takie roznice zmieniaja > styl pracy.
W rzeczywistej pracy (zawodowej) nie ma żadnej bariery psychologicznej. Po sieci 100Mbs to nie ma znaczenia.
Za to zasadnicze znaczenie mają ewentualne straty gdy padnie lokalny dysk. Gdy masz projekt na 50 osób, to awarie dysków są częste. Na serwerze robi się backupy jest porządna (a nie zabawkowa) macierz i jeden serwer statystycznie psuje się o dwa rzędy wielkości rzadziej niż któryś z kilkudziesięciu komputerów deweloperskich.
Commity robi się tak samo, co każdą spójną zmianę. Ba często nawet spójność zmiany jest iluzoryczna, bo w typowym większym systemie lokalnie to sobie można unit testy zrobić albo nawet i to nie pójdzie (bo lokalnie to masz Peceta, a system jest na zupełnie co innego).
>>> Druga podstawowa roznica jest to, ze masz dowolna liczbe swoich >>> calkowicie prywatnych klonow repozytorium, ktorych nikt nigdy nie musi >>> ogladac i na ktorych mozesz eksperymentowac ile dusza zapragnie bez >>> zadnego wstydu.
>> Z punktu widzenia firmy (a o tym właśnie pisze) to wstyd możesz sobie >> schować do kieszeni przed wejściem do budynku i wyjąć z powrotem przy >> wyjściu. Przypomnę, że piszę o projektach nie-opensource.
>> Nie rozumiem poza tym jak można się wstydzić własnego kodu. Chyba będę >> musiał zaprzestać organizowania code reviews, bo może ktoś się wstydzi >> poddawać pod komentarze swój własny kod.
> Jesli nikt nie wstydzi sie wlasnego kodu (lub nie powinien sie wstydzic), > to nie widze sensu organizowania przefgladow kodu
Czy Ty kiedykolwiek programowałeś zawodowo, w zespole, a nie tylko studencko/hobbystycznie + jakiś maleńki projekcik dla dorobienia?
> -- bo to chyba wlasnie > jest ich celem, zeby sklonic ludzi do pisania ladniejszego kodu.
Ich nadrzędnym celem jest wczesna eliminacja błędów. Drugim celem jest utrzymywalność kodu (czyli żeby był ładny, w znaczeniu czytelny).
> Wstyd > jest tutaj czynnikiem motywacyjnym. Mozesz sobie pisac jak to nie obchodzi > Cie co sobie o Twoim kodzie mysla inni i ze nie ma sie czego wstydzic -- > na pewno wszyscy sobie pomyslimy jaki wspanialy macho jestes. Ale wachanie > jest zawsze, nawet jesli ukrywane pod maska bezczelnosci.
I co z tego? Celem jest kod z możliwie małą liczbą pułapek dla późniejszych developerów i małą liczbą heisenbugów. Na jedno i drugie przeglądy kodu działają znakomicie.
>> Przecież wiadomo, że nikt nie tworzy od razu pięknego kodu. Jeśli >> piszesz tracer bullet to go wrzucasz do VCS z komentarzem, że to tracer >> bullet (w prywatnej gałęzi). Jak zadziała to jeśli jesteś dobrym >> programistą to go przepisujesz już poprawnie, jeżeli słabym to nigdy go >> poprawnie nie napiszesz. Będziesz go wtedy ukrywał na zawsze w prywatnym >> repozytorium?
> Jak nigdy nie zadziala, to po pewnym czasie prywatne repo skasuje albo > przeniose do archiwum i tyle. Osobiscie nie wierze w przepisywanie kodu > od zera -- probowalem tego kilka razy (pare razy nie mialem wyboru, bo > w gre wchodzila zmiana jezyka) i nigdy nie bylo to latwa. W sumie, patrzac > wstecz, to chyba nawet nigdy do konca nie bylo to przepisanie. Sam piszesz > ze nikt od razu nie napisze dobrego kodu -- zatem piszesz kiepski > i stopniowo ulepszasz. A jak juz jest wystarczajaco dobry zeby twoi > wspolpracownicy sobie nie wydrapali oczu, to laczysz z repozytorium > "glownym" i tyle.
A jak w między czasie sprzątaczka zaczepi odkurzaczem o komputer i dysk padnie to masz pisanie od początku... W przemyśle na takie zabawy nie ma miejsca.
>>> Rozproszone repozytoria maja >>> za zwyczaj taki "commit wyzszego stopnia" ktory pozwala na >>> synchronizacje dwoch repozytoriow -- najczesciej Twojego lokalnego i >>> centralnego, >>> firmowego. Diffy ogladasz z calego takiego "pusha" lub "pulla", wtedy >>> maja wiecej sensu (bo widzisz wiekszy kawalek i komentarze do kazdego >>> commita).
>> A jak to się różni od złączenia dwóch gałęzi w SVNie?
> Roznica w zasadzie jest tylko taka, ze robisz to kilkanascie razy dziennie > jako czesc normalnej pracy, a nie od swieta i z bolem tak wielkim, ze > wygodniej jest dana rzecz napisac od nowa.
Bo taka rzecz w normalnej organizacji pracy jest potrzebna od święta. To, że systemy rozproszone przyczynaiją się do robienia tego często jest w tej sytuacji ich poważną wadą a nie zaletą.
>>> Wydaje mi sie, ze komentarz o "pryszczerskich projektach" to cos w >>> rodzaju hasla "sikajac z wiaterm idziesz na latwizne" :)
>> Przeczytaj jeszcze raz wątek, bo to nie moje słowa.
> Ale przeciez ja nie twierdze ze sa Twoje. Nie prowadze tej dyskusji > wylacznie z Twoja osoba, nawet Cie nie znam -- staram sie przyczynic > do pokazania roznic miedzy tradycyjnym i rozproszonym systemem wersji > oraz pokazac zalety tego drugiego. Nie ma w tym nic osobistego.
> Chcialem zaznaczyc, ze osobiscie nie mam nic do uzytkownikow SVN-a, > i cieszy mnie, ze rasowi wyjadacze potrafia uzyc tego poteznego > narzedzia do skonstruowania sobie czegos na ksztalt wspolczesnych > rozproszonych systemow zarzadzania wersjami -- uzywajac prywatnych > galezi i podobnych mechanizmow. Osobiscie jednak latwiej mi jest > se nauczyc samych tylko podstwa systemu ktory juz ma to wbudowane.
Najwygodniej jest nie musieć stosować rzeczy do niczego w pracy niepotrzebnych. Dlatego branche robi się rzadko bo ich celem jest rzeczywisty branch (np. wersja działąjąca u klienta "na produkcji") a nie prywatne zabawy koderów (które są w takiej sytuacji szkodliwe)
pzdr -- "Never underestimate the power of human stupidity" -- L. Lang
On 2008-05-06, citizen Sebastian Kaliszewski testified:
> Bart Ogryczak wrote: >>>> Rozproszone mają sens tylko dla pryszczerskich projektów.
>>> Takich jak jądro Linuksa, Netbeans czy sunowska Java? :)
>> Dokładnie.
> AeLizm. > Jak JVM Suna jest pryszczerskim projektem, to wszystko poza sterowaniem > Boeingiem 777, elektorwnią atomową czy systemem antyrakietowym jest > pryszczerskim projektem.
Każdy, w którym mogą brać udział szerokie rzesze pryszczersów, jest projektem pryszczesrkim. Jak będzie system antyrakietowy, do którego kod będzie mógł modyfikować nastoletni "spec" z Zadupiesville, to też bedzie to pryszczerski projekt ;-P
> Rozproszone mają po prostu sens dla projektów developowanych "rozproszenie" > co nie ma nic do pryszczerstwa.
Oczywiście, że mają. Są to projekty Open Source albo Free Software.
> Ale tam gdzie chodzi się do pracy i > commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a > straty są istotne (nadużywanie branchów i wynikające z tego zdarzające się > od czasu do czasu błędy merdżowania, utrata istotnych danych bo pudełko pod > biurkiem zdechło, itp).
Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może być nawet i po przeciwnej stronie globu.
>>> Jedyną zaletą jest tworzenie swoich prywatnych commitów, ale w SVN też >>> można mieć prywatne gałęzie, a przynajmniej wszystko jest zawsze >>> backupowane na centralnym serwerze. >> zaletą jest szybkość. >> do zdalnego repozytorium nigdy nie będziesz miał tak szybkiego dostępu >> jak do lokalnego.
> Może jak się robi edycję grafiki czy coś w ten deseń, to to ma jakiekolwiek > znaczenie. W przypadku kodu źródłowego nie ma żadnego. Zmiany będą miały > nie więcej niż kilka KB i to przed kompresją. Więc będzie działać szybko, > nawet jeśli używasz modemu 14,4kbps ;-P
To zależy jakie zmiany są robione i ile jest branchy. U mnie pobieranie całego projektu przez ocean po CVS trwa zdecydowanie dłużej niż godzinę. Jednoplikowe poprawki to rzeczywiście żaden problem.
> Bart Ogryczak pisze: >>>> Jedyną zaletą jest tworzenie swoich prywatnych commitów, ale w SVN >>>> też można mieć prywatne gałęzie, a przynajmniej wszystko jest zawsze >>>> backupowane na centralnym serwerze. >>> zaletą jest szybkość. >>> do zdalnego repozytorium nigdy nie będziesz miał tak szybkiego dostępu >>> jak do lokalnego.
>> Może jak się robi edycję grafiki czy coś w ten deseń, to to ma >> jakiekolwiek >> znaczenie. W przypadku kodu źródłowego nie ma żadnego. Zmiany będą miały >> nie więcej niż kilka KB i to przed kompresją. Więc będzie działać szybko, >> nawet jeśli używasz modemu 14,4kbps ;-P
> To zależy jakie zmiany są robione i ile jest branchy. U mnie pobieranie > całego projektu przez ocean po CVS trwa zdecydowanie dłużej niż godzinę. > Jednoplikowe poprawki to rzeczywiście żaden problem.
No dobra, ale tak często pobierasz projekt+wszystkie branche?
>>>>> Jedyną zaletą jest tworzenie swoich prywatnych commitów, ale w SVN >>>>> też można mieć prywatne gałęzie, a przynajmniej wszystko jest zawsze >>>>> backupowane na centralnym serwerze. >>>> zaletą jest szybkość. >>>> do zdalnego repozytorium nigdy nie będziesz miał tak szybkiego dostępu >>>> jak do lokalnego. >>> Może jak się robi edycję grafiki czy coś w ten deseń, to to ma >>> jakiekolwiek >>> znaczenie. W przypadku kodu źródłowego nie ma żadnego. Zmiany będą miały >>> nie więcej niż kilka KB i to przed kompresją. Więc będzie działać szybko, >>> nawet jeśli używasz modemu 14,4kbps ;-P >> To zależy jakie zmiany są robione i ile jest branchy. U mnie pobieranie >> całego projektu przez ocean po CVS trwa zdecydowanie dłużej niż godzinę. >> Jednoplikowe poprawki to rzeczywiście żaden problem.
> No dobra, ale tak często pobierasz projekt+wszystkie branche?
> Bart Ogryczak pisze: >>>> Jedyną zaletą jest tworzenie swoich prywatnych commitów, ale w SVN też >>>> można mieć prywatne gałęzie, a przynajmniej wszystko jest zawsze >>>> backupowane na centralnym serwerze. >>> zaletą jest szybkość. >>> do zdalnego repozytorium nigdy nie będziesz miał tak szybkiego dostępu >>> jak do lokalnego.
>> Może jak się robi edycję grafiki czy coś w ten deseń, to to ma jakiekolwiek >> znaczenie. W przypadku kodu źródłowego nie ma żadnego. Zmiany będą miały >> nie więcej niż kilka KB i to przed kompresją. Więc będzie działać szybko, >> nawet jeśli używasz modemu 14,4kbps ;-P
> To zależy jakie zmiany są robione i ile jest branchy. U mnie pobieranie > całego projektu przez ocean po CVS trwa zdecydowanie dłużej niż godzinę. > Jednoplikowe poprawki to rzeczywiście żaden problem.
Po ssh, gdzie ssh ma kompresję ustawioną ma max? I co znaczy "pobieranie całego"? Przecież checkout się robi konkretnej wersji a nie wszystkich branchy.
> Bart Ogryczak pisze: >> I co znaczy "pobieranie całego"? Przecież checkout się robi >> konkretnej wersji a nie wszystkich branchy. > Ale ten jeden snapshot to setki megabajtów.
A ile zajmą wszystkie snapshoty wszystkich developerów w VCS-ie rozproszonym? Przecież też się trzeba od czasu do czasu zsynchronizować z resztą, nie?
-- <:> Roger, MoonWolf Out <:>|So fu*king what (::) (::)| (:)JID:moonwolfATjabberpl.org(:)| http://karakkhaz.prv.pl
>> Bart Ogryczak pisze: >>> I co znaczy "pobieranie całego"? Przecież checkout się robi >>> konkretnej wersji a nie wszystkich branchy. >> Ale ten jeden snapshot to setki megabajtów.
> A ile zajmą wszystkie snapshoty wszystkich developerów w VCS-ie > rozproszonym? Przecież też się trzeba od czasu do czasu zsynchronizować > z resztą, nie?
Ha, to już wiem skąd się bierze te 80% ruchu w Internecie generowanego przez P2P ;-)
Bart Ogryczak wrote: >>>>> Rozproszone mają sens tylko dla pryszczerskich projektów.
>>>> Takich jak jądro Linuksa, Netbeans czy sunowska Java? :)
>>> Dokładnie.
>> AeLizm. >> Jak JVM Suna jest pryszczerskim projektem, to wszystko poza sterowaniem >> Boeingiem 777, elektorwnią atomową czy systemem antyrakietowym jest >> pryszczerskim projektem.
> Każdy, w którym mogą brać udział szerokie rzesze pryszczersów, jest > projektem pryszczesrkim. Jak będzie system antyrakietowy, do którego kod > będzie mógł modyfikować nastoletni "spec" z Zadupiesville, to też bedzie > to pryszczerski projekt ;-P
Taka twoja definicja. Z definicjami się nie dyskutuje. Choć mnie by bardziej interesowały kryteria wg których kod jest włączany do projektu.
Bo tak to i Windows jest "pryszczerski", bo wzięli gotowe fragmenty "pryszczerskiego" BSD (choćby w obsłudze sieci). Jeśli kod przed wpuszczeniem jest odpowiednio weryfikowany to niech sobie pochodzi od kogokolwiek. BTW. w wielu projektach OS wpuszcza się spoza zespołu tylko maleńkie fragmenty -- głównie poprawki bugów. Celem otwarcia źródeł jest darmowy zewnętrzny przegląd kodu + darmowe testy + darmowe poprawki.
>> Rozproszone mają po prostu sens dla projektów developowanych >> "rozproszenie" co nie ma nic do pryszczerstwa.
> Oczywiście, że mają. Są to projekty Open Source albo Free Software.
Też nie koniecznie. Rzadko bo rzadko, ale nie muszą być otwarte.
>> Ale tam gdzie chodzi się do pracy i >> commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a >> straty są istotne (nadużywanie branchów i wynikające z tego zdarzające >> się od czasu do czasu błędy merdżowania, utrata istotnych danych bo >> pudełko pod biurkiem zdechło, itp).
> Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może > być nawet i po przeciwnej stronie globu.
Problem wtedy taki, że minimalnie wolniej działa. Choć w praktyce to ma małe znaczenie, bo w przeciwieństwie do różnych wypisywanych w tym wątku opwiastek, to commity, zwłaszcza częste, dotyczą małej liczby danych, więc idą szybko. Kłopot jest tylko z trzymaniem w repozytorium binariów typu dokumentacja w Wordzie czy PDFach, obrazki itp.
pzdr -- "Never underestimate the power of human stupidity" -- L. Lang
> Bart Ogryczak wrote: >>>>>> Rozproszone mają sens tylko dla pryszczerskich projektów.
>>>>> Takich jak jądro Linuksa, Netbeans czy sunowska Java? :)
>>>> Dokładnie.
>>> AeLizm. >>> Jak JVM Suna jest pryszczerskim projektem, to wszystko poza sterowaniem >>> Boeingiem 777, elektorwnią atomową czy systemem antyrakietowym jest >>> pryszczerskim projektem.
>> Każdy, w którym mogą brać udział szerokie rzesze pryszczersów, jest >> projektem pryszczesrkim. Jak będzie system antyrakietowy, do którego kod >> będzie mógł modyfikować nastoletni "spec" z Zadupiesville, to też bedzie >> to pryszczerski projekt ;-P
> Taka twoja definicja. Z definicjami się nie dyskutuje. Choć mnie by bardziej > interesowały kryteria wg których kod jest włączany do projektu.
> Bo tak to i Windows jest "pryszczerski", bo wzięli gotowe > fragmenty "pryszczerskiego" BSD (choćby w obsłudze sieci).
Przyszczerski to jest Free/OpenBSD. BSD (jak można domyśleć się z nazwy) należy do Uniwersytetu Kalifornijskiego w Berkeley.
>>> Rozproszone mają po prostu sens dla projektów developowanych >>> "rozproszenie" co nie ma nic do pryszczerstwa.
>> Oczywiście, że mają. Są to projekty Open Source albo Free Software.
> Też nie koniecznie. Rzadko bo rzadko, ale nie muszą być otwarte.
Oh? Możesz podać jakiś przykład?
>>> Ale tam gdzie chodzi się do pracy i >>> commituje na serwer stąjący w tym samym budynku, zysku nie ma żadnego, a >>> straty są istotne (nadużywanie branchów i wynikające z tego zdarzające >>> się od czasu do czasu błędy merdżowania, utrata istotnych danych bo >>> pudełko pod biurkiem zdechło, itp).
>> Ale nie musi być w tym samym budynku, wystarczy, że ten sam VPN. Może >> być nawet i po przeciwnej stronie globu.
> Problem wtedy taki, że minimalnie wolniej działa. Choć w praktyce to ma małe > znaczenie, bo w przeciwieństwie do różnych wypisywanych w tym wątku > opwiastek, to commity, zwłaszcza częste, dotyczą małej liczby danych, więc > idą szybko. Kłopot jest tylko z trzymaniem w repozytorium binariów typu > dokumentacja w Wordzie czy PDFach, obrazki itp.
SVN używa xdelta, dosyć dobrze działa na binarkach.
|
