Love, Freedom and Open Source

• Blog
• Tlog
• O mnie

Komentarze:

1. Zal:
   29 Cze 2009, 20:54:04

   Warto zauważyć, że czasy o których piszesz tak właściwie niewielkie znaczenie mają dla użytkownika. Dlaczego? Chyba tylko Bazaar (masz literówkę w pierwszym akapicie) w pewnym momencie wykracza ponad 2s czasu działania. Reszta czasów jest dla użytkownika niezauważalna. Dlatego też to nie wydajność świadczy o systemie kontroli wersji, a jego funkcjonalność i wsparcie ze strony zewnętrznych aplikacji.
   
   Pod względem przenośności, wsparcia ze strony IDE i różnego rodzaju nakładek graficznych Mercurial wygrywa zarówno z Bazaarem, jak i Gitem. Również takie firmy, jak np. Google wspierają Mercuriala. O ile wybór systemu kontroli wersji uważam za wybór zależny od indywidualnych upodobań programisty, tak jednak większą popularność zyskuje obecnie Hg.
   
   Przy czym i tak Subversion króluje pod względem popularności. Scentralizowane systemy kontroli wersji jeszcze przez długi czas będą się sprawdzać, chociażby we wszelkiego rodzaju firmach, gdzie rozproszone systemy wcale nie są tak dobrze dopasowane do modelu działania firmy.

2. Matthew:
   29 Cze 2009, 21:08:36

   Commitowanie dużej ilości zmian też jest równie wolne w hg (choć fakt, że kto commituje tyle zmian?). Porównanie tego co oferują poszczególnie DVCS jest ciężkie bo nikt nie zna na tyle wszystkich, żeby móc to rzetelnie zrobić. Poza tym musisz zauważyć, że Django samo w sobie jest małym projektem a test został zrobiony na wydajnym sprzęcie. Podejrzewam, że jakbym wziął coś większego na wolniejszym to by różnice były większe.
   
   Co do wsparcia. Tutaj bym się nie zgodził, że hg jest lepiej wspierany przez aplikacje. Zarówno Eclipse jak i NetBeans mają wtyczki dla gita. A Google Code bym się nie przejmował. Sam github jest znacznie lepszy jeżeli chodzi o bycie repozytorium. I popularność to też zależy gdzie rozpatrujesz. Mercurial jest chyba popularniejszy wśród aplikacji webowych i tych silnie portowanych (jak FF), ale na samym Linuksie lepiej trzyma się git.
   
   Swoją drogą to z chęcią bym zobaczył reckę tortoisegit i jak wygląda wydajność gita na Windowsie.

3. Albi:
   29 Cze 2009, 21:46:25

   Matthew: Korzystałeś z tych wtyczek? Daj mi coś działającego chociaż w małej części tak dobrze jak Subclipse to pogadamy. Te gitowe wtyczki są kolokwialnie mówiąc "do dupy".

4. Matthew:
   29 Cze 2009, 21:51:13

   @Albi: nie bo jeszcze nie miałem okazji, ale mam zamiar na potrzeby pracy sprawdzić git-svn i integrację gita z Eclipsem. Wtedy wypowiem się na temat ich jakości. A poza tym, jak nie wtyczki to jest konsola. ;D

5. AdamK:
   29 Cze 2009, 22:43:45

   Pierwsze 2 badania (założenie repozytorium, dodanie plików) są moim zdaniem pomijalne. Jedno i drugie robi się dość rzadko.
   
   Co do reszty czasów - to tutaj (http://www.youtube.com/watch?v=4XpnKHJAok8) Linus się wypowiada że jak masz do nałożenia 2000 patchy, to róznica 1s a 2s nagle jest bardzo dużą różnicą. Dlatego właśnie Git ma takie a nie inne cechy.

6. morii:
   30 Cze 2009, 00:06:15

   co do wtyczek, to w netbeanse nb4git jest takie sobie, coś tam mu się walnie zawsze , podstawowe operacje można wykonać, aczkolwiek trzeba się wspierać komendami...
   faktycznie daleko do poziomu obsługi svn'a

7. Hoppke:
   30 Cze 2009, 11:27:32

   Nawet przy 2k patchy (ciekawe jak często zdarza się taka nawałnica...), po 2s każdy, całkowity czas wynosi tylko nieco ponad 1h. Przypuszczam, że to "tyle co nic" w porównaniu z czasem jakiego człowiek potrzebuje, by te 2k patchy najpierw przejrzeć i wyselekcjonować.
   
   Też uważam, że takie różnice to nic wartego uwagi (wszyscy wymienieni tu konkurenci będą się sprawdzać zarąbiście dobrze, bo 99% czasu pracy zejdzie i tak na inne czynności).
   
   A Eclipse i owszem, ma wtyczkę do git-a, ale jej funkcjonalność jest bardzo "alpha".
   
   No i gitfani powinni się w końcu zająć gitem na innych platformach. W moim ostatnim miejscu pracy migracja na gita została odwołana właśnie dlatego, że poza linuksem git działa "tak sobie" (a sporo developerów siedziało na winxp).

8. Zal:
   30 Cze 2009, 11:31:27

   Git sprawdza się obecnie przy tworzeniu jądra Linuksa - do tego został stworzony - i przy pracy pod Linuksem - z myślą o nim został stworzony.
   
   Tak, jak wspomniałem - wybór systemu kontroli wersji zależy w głównej mierze od naszego gustu i potrzeb. Trzeba jednak obiektywnie stwierdzić, iż Git ma ograniczone pole działania. Problemy z przenośnością i brak dobrego wsparcia ze strony IDE/nakładek GUI sprawa, że nie może się upowszechniać w takim tempie, jak Mercurial.
   
   Dlatego też wnioskuję, że wielce prawdopodobnym jest, iż w przyszłości odpowiednikiem SVN-a w świecie scentralizowanych systemów będzie Mercurial ;]

9. AdamK:
   30 Cze 2009, 11:32:32

   @Hoppke: obejrzyj sobie prezentację do której link podałem - Linus tam bardzo ciekawie mówi. Jest jeszcze inna, bardzo dobra prezentacja tutaj: http://www.youtube.com/watch?v=8dhZ9BXQgc4
   
   Pozatym git to nie tylko prędkość. Linus podaje ciekawy fakt: kiedy projekt KDE przesiadał się z jednego systemu wersji na inny, całe repozytorium CVS ważyło ok. 8GB. SVN rozdmuchał to do ok 40GB. Wynik Gita: 1.3GB (z pełną historią wersji itp.)

10. Hoppke:
    30 Cze 2009, 11:53:05

    I jeszcze jedno -- dlaczego wszyscy fani gita, gdy tylko cokolwiek powiem, odsyłają mnie do prezentacji Linusa? Ja to serio widziałem i nie, nadal do mnie nie przemawia.
    
    I serio, gdy dziesiąta osoba z kolei odsyła mnie na YT "najlepiej sam zobacz, jak Linus to wyjaśnia", to mi witki opadają :)
    
    A te 40GB to... nie trafia do mnie.
    Po pierwsze nie wiem, czy ludki od KDE czegoś nie spieprzyły (możliwe, że jeden czy drugi VCS daje się jakoś tweakować), po drugie nie wiem, czy ten zysk Gita jest przenośny. Ale przede wszystkim: w domowej maszynie mam w tej chwili ponad 1TB przestrzeni dyskowej; w większości firm, które mają "continuous integration" i trzymają historię wszystkich kompilatów, same zbudowane binaria sumują się na ogół w setki GB.
    
    Ten argument może mieć znaczenie np. dla takich tworów jak Sourceforge, ale w większości zastosowań kilkadziesiąt GB w jedną czy drugą stronę? nikt nie zauważy nawet. Sam w zeszłym tygodniu przypadkiem zauważyłem, że mój lokalny profil użytkownika przekroczył 50GB (i zauważyłem tylko dlatego, że mam go automatycznie backupowanego gdzieś w firmowym lanie i przywaliłem w quotę :)
    
    A nawet sam Linus radził ludziom z KDE by rozbili repozytorium na masę podprojektów przed migracją na gita, bo o ile w SVN mogą sobie spokojnie wyjąć jakiś pojedynczy moduł i pracować lokalnie na 100MB źródeł (np. tylko kdelibs-common), to git nie pozwoli im już na taką swobodę i będą musieli pociągnąć z repozytorium wszystko. Zawsze jest coś za coś.

11. Matthew:
    30 Cze 2009, 12:03:36

    @Hoppke: ale nie ma potrzeby selekcjonować ich. To jest na zasadzie zwykłego ściągania delt od osób którym ufamy. Co do szybkości, to się tylko tak wydaje że sekunda nie robi różnicy. Jak robiłem test, to wcisnąłem enter i git już zdążył przemielić wszystko. hg i bzr to jednak zajmowało. Pamiętaj że przesiadka z wolniejszego na szybsze będzie niezauważalna, ale na odwrót będzie już bardzo męcząca (nawet jeżeli to tylko złudzenie, o psychikę też trzeba dnać ;)). A fan gita nie zrobią go na inne platformy, bo nie do tego on został stworzony. Window jest po prostu do tego za wolny. Poza tym po co Linus miałby robić coś na konkurencyjny system? Bo ktoś tak chce? Jak chcesz to sobie zrób, nikt Ci nie broni. ;] Poza tym nie może być aż tak źle skoro Qt (międzyplatformowe), Perl (również międzyplatformowe), RoR (to samo) czy Android swoje repa oparły a gitcie.
    
    @Zal: Ty już się tak nie podniecaj, bo gadasz tak bo sam używasz Mercuriala, więc zrobisz wszystko, żeby on był najważniejszy. I Mercurial wcale tak szybko się nie rozrasta jakby Ci się wydawało.
    
    @Hoppke (2): SVN taką ma już strukturę na dysku, że się tak rozpycha. A twierdzenie, że ta mała pojemność nie jest przenośna... to jakby powiedzieć, że ten sam algorytm, zaimplementowany w ten sam sposób dla tych samych danych wejściowych daje dwa różne wyniki. A że Linus radzi... Fakt, jest to pewne ograniczenie gita ale nie zostało ono zrobione specjalnie. Da się wyciągnąć jeden konkretny plik, tylko jest to dość kosztowne. Poza tym jak twierdzi Linus: co kogo obchodzi jeden plik przy repo w którym są ich tysiące? Poza tym repo KDE i tak jest podzielone w taki sposób. Ot to jest po prostu sposób pracy z gitem w przypadku baaaardzo dużych projektów z dużą ilością modułów. Tak samo jak SVN jest scentralizowany. Tylko sposób pracy, nie jest to ani złe, ani dobre, po prostu jest inne.

12. Zal:
    30 Cze 2009, 12:08:52

    @Matthew:
    
    Nawet nie wiesz, jak wiele wysiłku zaczęli ostatnio wkładać w to, aby Git dobrze sprawował się pod Windowsem. Bez tego nie odniesie większego sukcesu - pozostanie niszowym systemem.
    
    Co do Mercuriala - to nie jest kwestia podniecania się nim. Zapoznałem się z "Wielką Trójcą", poczytałem na ich temat i obserwowałem, jak się rozwijają. Używam Mercuriala, ponieważ staje się standardem pośród zdecentralizowanych rozwiązań. Ludzie, którzy się nim zajmują mocno działają w stronę jego upowszechnienia - coraz więcej IDE posiada wsparcie dla Mercuriala OOTB, istnieją dobre narzędzia graficzne do jego obsługi, a przy okazji pojawia się wsparcie ze strony większych firm. Mercurial nie jest najlepszy we wszystkim - w wielu przypadkach Git go przerasta (Bazaara w ogóle nie biorę pod uwagę ;D) - ale to właśnie Hg powoli zyskuje popularność.

13. AdamK:
    30 Cze 2009, 12:11:06

    Co do windows i narzędzi: używam (muszę) Gita pod windows z TortoiseGIT'em. Świetne narzędzie klasy TortoiseCVS i TortoiseSVN :)

14. AdamK:
    30 Cze 2009, 12:12:26

    Git jest napewno przenośny w sensie klient windows może współpracować z klientem pod linuxa (przećwiczone), nie wiem czy samo repozytorium jest przenośne (w sensie kopiowania plików)

15. Karol "Zal" Zalewski:
    30 Cze 2009, 12:13:09

    Swoją drogą - dla Mercuriala również istnieje "TortoiseHg":http://bitbucket.org/tortoisehg/stable/wiki/Home. Dla wielu kumpli Tortoise* to wybawienie :D

16. Matthew:
    30 Cze 2009, 12:40:05

    @Zal: Tylko że ten wysiłek wkładają ludzie spoza deweloperów gita. Dwa, że hg też jest niszowy i podejrzewam, że jeszcze bardziej niż git. I wcale nie jest standardem i standardem się nigdy nie stanie. Ani na Windzie bo tam albo króluje SVN albo jakieś hamerykańskie wynalazki (Alana zapytaj, on się lubi w pracy męczyć z tym ;D) ani tym bardziej na Linuksie gdzie z zdecentralizowanych jest git. To, że go ekipa hg wciska wszędzie gdzie się da to jeszcze nic nie znaczy. Taki EGit został oficjalnym projektem w ramach Eclipse (w swoją drogą to nie wiem po kiego grzyba przepisywać gita na javę), hg nie. Napisanie wtyczki która by dawała podstawową obsługę dowolnego VCS to jest kwestia 2-3 wieczorów. Druga kwestia czy ktoś tego potrzebuje (to tak jakbym napisał wsparcie dla BrainF*ck dla Eclipse, a później się chwalił, że to coraz popularniejszy język i staje się standardem bo ma X wtyczek do odpowiednich IDE). ;P

17. Zal:
    30 Cze 2009, 12:48:32

    @Matthew: NetBeans widziałeś? Oficjalne wsparcie, dołączane standardowo do IDE. Sun preferuje Mercuriala z rozproszonych. Google? Wsparcie finansowe dla developerów TortoiseHg oraz wdrożenie Mercuriala do Google Code. SVN-a jeszcze długo nic nie przebije, a Mercurial walczy o dominację w świecie rozproszonych systemów.

18. Matthew:
    30 Cze 2009, 13:06:25

    NetBeans vs. Eclipse. (swoją drogą NetBeans ma też wsparcie OOTB dla CVSa :D)
    Google finansowo wspiera wszystko co w Pythonie bo mają w tym własny interes.
    A Sun... Oracle przejmuje Suna. Oracle wspiera gita. Sun będzie wspierał gita? oO
    
    Z resztą... w ostatnim zdaniu tej notki masz moje polecenie używania hg dla nie-posixów (problemy z czytaniem ze zrozumieniem? ;P), a sam hg nie był, nie jest i nie będzie standardem wśród zdecentralizowanych.

19. Karol "Zal" Zalewski:
    30 Cze 2009, 13:09:25

    @Matt: Co do interesu Google - ważne, że wspierają. To tak, jak z MS. Nie ważne, czym jest dane rozwiązanie, zaś ważne jest to, że jest przez MS wspierane. Nie oznacza to, iż popieram takie zachowanie, ale z pewnością wpływa ono na popularność danego rozwiązania ;]
    
    A z Sunem i Oracle to ja bym się zastanowił raczej, jak to będzie z Btrfs vs ZFS. A do tego jestem ciekaw, czy Oracle będzie kontynuować politykę Suna.

20. Stanisław 'dozzie' Klekot:
    30 Cze 2009, 13:18:31

    A tak z głupia frant zapytam, co daje tzw. "integracja z IDE"? Bo średnio sobie to wyobrażam, z wyjątkiem wyświetlania różnic w edytorze IDE.

21. Matthew:
    30 Cze 2009, 13:19:41

    @dozzie: zamiast klikać w terminalu git commit -a -m"foo" wyklikujesz to z menu. ;]

22. Zal:
    30 Cze 2009, 13:22:09

    @dozzie: Widziałeś GUI dla systemów kontroli wersji? Pozwalają na wykonywania poleceń z GUI, ale to akurat ich najmniejsza "zaleta". Możesz poruszać się po strukturze katalogów i plików dla danej wersji. Przy pomocy myszy porównywać zawartość plików itp. Integracja z IDE daje od razu możliwość automatycznego dołączania do repozytorium danych plików, a np. niedopuszczania binarek.
    
    W ogólności nie daje to niczego, czego nie miałby klient tekstowy. Ja osobiście nie cierpię klikanych wersji SVN-a, czy też Mercuriala, ale dla wielu osób jest to spore udogodnienie.

23. Stanisław 'dozzie' Klekot:
    30 Cze 2009, 13:23:43

    Ah so. Dzięki.

24. riddle:
    30 Cze 2009, 13:28:56

    Prezentacja Linusa jest o kant dupy potłuc, bo on zakłada, że każdy wie co to Git oraz że każdy uznaje jego wyższość i wszechwiedzę.
    
    Jeśli ktoś chce się dowiedzieć czym jest Git i dlaczego jest stokroć lepszy od SVN/CVS (nie mam pojęcia jak z systemami opisanymi we wpisie), to proszę: http://www.youtube.com/watch?v=8dhZ9BXQgc4
    
    Git nie jest tylko dla nerdów i -iksów, http://github.com tego najlepszym przykładem.

25. Hoppke:
    30 Cze 2009, 13:52:00

    "ale nie ma potrzeby selekcjonować ich. To jest na zasadzie zwykłego ściągania delt od osób którym ufamy"
    
    To niech to robi zautomatyzowany skrypt. Może z crona. Nawet nie zauważę kiedy działał...
    
    "A fan gita nie zrobią go na inne platformy, bo nie do tego on został stworzony."
    
    To nie fan w takim razie, tylko gitowy moher.
    
    Nie ma co marzyć o dominacji na rynku z takim podejściem. Wybije się ten DVCS, który będzie potrafił odpowiedzieć na potrzeby biznesu.
    
    "Co do szybkości, to się tylko tak wydaje że sekunda nie robi różnicy. Jak robiłem test, to wcisnąłem enter i git już zdążył przemielić wszystko. hg i bzr to jednak zajmowało."
    
    Zysk kilkunastu-kilkudziesięciu sekund w ciągu dnia nie robi mi różnicy. Tym bardziej, jeśli w zamian muszę oddać inne korzyści (np. bardziej wyrafinowane narzędzia wspomagające czy lepszą integrację z IDE).
    
    "Poza tym po co Linus miałby robić coś na konkurencyjny system?"
    
    A to poza Linusem nikt inny nie umie Gita rozwijać?
    
    "Poza tym nie może być aż tak źle skoro Qt (międzyplatformowe), Perl (również międzyplatformowe), RoR (to samo) czy Android swoje repa oparły a gitcie."
    
    Znam też sporo projektów używających Perforce. Każdy system kontroli wersji jest przez kogoś gdzieś używany. Kwestia bilansu zysków i strat.
    
    "Poza tym jak twierdzi Linus: co kogo obchodzi jeden plik przy repo w którym są ich tysiące?"
    
    Obchodzi bardzo każdego, kto pracuje z modularnym projektem. Jeśli chcę sobie ściągnąć i przekompilować kpdf, to nie chcę ściągać od razu kodu kickera, wszystkich bibliotek itp.
    
    Nie zapominaj, że Linux jako projekt jest bardzo specyficzny.
    
    "A twierdzenie, że ta mała pojemność nie jest przenośna... to jakby powiedzieć, że ten sam algorytm, zaimplementowany w ten sam sposób dla tych samych danych wejściowych daje dwa różne wyniki."
    
    A gwarantujesz, że dane wejściowe są takie same? Git musiałby mieć niezłą abstrakcję warstwy składowania danych by np. różnice w systemach plików nie miały na niego wpływu. Pomyśl np. o MySQL -- pod Windowsem nazwy kolumn w zapytaniach SQL są case-insensitive, w MySQL pod Linuksem są już case-sensitive. Jeśli Git uzyskuje "kompaktowe" repozytorium np. dzięki sprytnemu użyciu linków (czy innych cech występujących na Linuksach, np. składowaniu plików na reiserfs), to na innym systemie operacyjnym może nie osiągać takich wyników.
    
    Z tego co widzę w ogłoszeniach o pracę, to w wymaganiach o wiele częściej pojawia się Mercurial niż Git.
    
    "swoją drogą to nie wiem po kiego grzyba przepisywać gita na javę"
    
    Do SVN też stworzono natywny "connector". Łatwiej się integruje z javowym softem, o niebo łatwiej o przenośność, można robić cholernie złożone przetwarzania niskim kosztem (JVM jest baaardzo wydajny). No i łatwiej to potem utrzymywać.

26. matek:
    30 Cze 2009, 13:54:30

    fajne porównanie. Ciekawi mnie jeszcze jak to wszystko wygląda w przypadku ciągniecia/udostępniania kodu innym osobom. Przez net. Jest gdzieś takie porównanie (bo chyba DVCSy commitują domyślnie "na dysk", jo?)?

27. riddle:
    30 Cze 2009, 14:00:27

    Hoppke, a Google nadal używa CVS. Zmiana takiego systemu jest po prostu zbyt ciężka. Nie znaczy to, że CVS jest dobry. Jest paskudny. Podane przykłady to projekty do których trzeba równać jakością.
    
    Git nie nadaje się do wszystkiego, zwłaszcza dlatego, że traktuje pliki jako część większego projektu (wspomniany brak możliwości wyciągnięcia 1 pliku z repo). Natomiast do web developmentu jest w sam raz. I odpada od razu problem wsparcia na Windowsie – przekraczając pewien poziom wiedzy znikasz z tego systemu, wybierając coś uniksowego. Moher czy nie, webdev na Windowsie to tylko w .NET… no ale wtedy mamy Microsoft Version Control System™ 2000 a nie Gita.

28. Jajcuś:
    30 Cze 2009, 14:07:16

    Git powstał jako „szybki hack” na potrzeby kodu jądra Linuksa. Wtedy nie było nic innego co by się do tego nadało, a BitKeeper się na Linuksa wypiął. Linus zrobił więc coś, co minimalnym nakładem kosztów pozwoli dalej rozwijać Linuksa, przynajmniej tymczasowo, aż się znajdzie coś odpowiedniego. I Git sobie poradził niespodziewanie dobrze. I jeśli inne projekty zaczynają z Gita korzystać, to jest to niesamowity sukces.
    Mercurial, zdaje się, od razu powstawał jako poważny projekt… no to trochę blado wypada przy tym „szybkim hacku”, nawet jeśli w paru miejscach jest technicznie lepszy…
    A kłócenie się o to który lepszy, który będzie lepszy i który jest standardem nie ma najmniejszego sensu. Do rozwijania Linuksa pewnie długo Git będzie najlepszy, bo został właśnie pod ten projekt stworzony według potrzeb, sposobu pracy i przyzwyczajeń opiekunów Linuksa. Do innych rzeczy? To co kto woli. Mnie, na przykład, wciąż Subversion zupełnie wystarcza :)

29. Matthew:
    30 Cze 2009, 14:13:55

    @matek: porównania przez internet nie ma sensu robić. Chciałem zobaczyć jak szybko zajmuje klonowanie w przypadku każdego dvcs, ale różnica w prędkościach ściągania z poszczególnych hostingów była za duża. To czy system podczas pushowania na serwer będzie chodził 5 zamiast 1 sekundy nie robi, bo prawdopodobnie i tak łącze Cie spowolni na tyle, że tego nie zauważysz.
    
    @Hoppke:
    "To nie fan w takim razie, tylko gitowy moher."
    
    Ale czemu moher? Fani gita to przeważnie pingwiniarze z krwi i kości i nie używają Wind, czemu mieliby portować coś na system z którego nie korzystają?
    
    "Zysk kilkunastu-kilkudziesięciu sekund w ciągu dnia nie robi mi różnicy. Tym bardziej, jeśli w zamian muszę oddać inne korzyści (np. bardziej wyrafinowane narzędzia wspomagające czy lepszą integrację z IDE)."
    
    Póki tych malutkich zmian nie masz setek czy tysięcy. Myślę, że problem leży nie w kwestii czego używać, ale jak rozwijać oprogramowanie. Ty chyba za bardzo się trzymasz zamkniętego modelu, czy nawet katedry.
    A moje IDE integruje się bardzo dobrze z gitem (tak samo jak z SVNem czy Perforce).
    
    "Obchodzi bardzo każdego, kto pracuje z modularnym projektem. Jeśli chcę sobie ściągnąć i przekompilować kpdf, to nie chcę ściągać od razu kodu kickera, wszystkich bibliotek itp."
    
    Ale to są już oddzielne projekty (nie moduły), więc powinny być w oddzielnych repo. Nawet dla modułów warto porobić oddzielne repo. Nie widzę w czym problem. Jeżeli mam do wyboru 3 repa wiecej, a repo które się rozrasta kilkukrotnie to wolę to pierwsze. Poza tym prawdopodobnie potrzebujesz nowych wersji bibliotek przy nowym kpdf.
    
    PS. Polecam Okulara, serio, fajniejszy i ma wsparcie dla dużej liczby plików. ;]
    
    "A gwarantujesz, że dane wejściowe są takie same?"
    
    Chodzi Ci o to, że mogę skopiować repo z Linuksa, odpalić klienta na Windzie i czy będzie działało? Nie próbowałem tego, ale z chęcią zobacze. Git w swoim repo ma tylko pliki i katalogi, więc raczej większego problemu z tym nie powinno być.
    
    "Do SVN też stworzono natywny "connector". Łatwiej się integruje z javowym softem, o niebo łatwiej o przenośność, można robić cholernie złożone przetwarzania niskim kosztem (JVM jest baaardzo wydajny). No i łatwiej to potem utrzymywać."
    
    W Javie zrobili coś takiego jak JGit. Ale nie widzę sensu tego, bo to i tak zabija wydajność gita. W przypadku SVNa tego nie widać, bo on i tak jest na tyle powolny (i nie siedzi u nas), że nie ma to żadnego znaczenia.

30. Hoppke:
    30 Cze 2009, 15:39:36

    "czemu mieliby portować coś na system z którego nie korzystają"
    
    Większość projektów OS zaczyna się od prywatnych narzędzi; prawdziwy sukces odnoszą jednak tylko te, które wyszły poza etap "robię to wyłącznie dla siebie".
    
    "Póki tych malutkich zmian nie masz setek czy tysięcy."
    
    Oczywiście. Ale projekty, które mają setki czy tysiące takich zmian dziennie to margines. Ciekaw jestem ile commitów dziennie (mediana) ma Linux...
    
    "Ty chyba za bardzo się trzymasz zamkniętego modelu, czy nawet katedry."
    
    Trzymam się tego modelu, który mi płaci. A że o wiele łatwiej jest zarobić będąc programistą CS, to i siedzę w zamkniętym modelu. To nic złego chyba?
    
    "Ale to są już oddzielne projekty (nie moduły), więc powinny być w oddzielnych repo."
    
    No właśnie nie do końca, te projekty często zachowują się jak moduły (np. odbranchowujesz równocześnie dużą ich część przygotowując kolejną generację produktu -- bo mają jakieś zależności między sobą i np. wiesz, że jak zmodyfikujesz biblioteki, to ileś-tam programów ich używających też trzeba będzie przerobić).
    
    "Nawet dla modułów warto porobić oddzielne repo."
    
    A jakie masz z tego korzyści, poza obejściem ograniczeń konkretnego DCVS?
    
    "Poza tym prawdopodobnie potrzebujesz nowych wersji bibliotek przy nowym kpdf."
    
    OK, w KDE to pewnie prawda. Ale nie znaczy to, że w innych projektach nie panują inne zasady.
    
    "Chodzi Ci o to, że mogę skopiować repo z Linuksa, odpalić klienta na Windzie i czy będzie działało?"
    
    Nie, bardziej czy Git tak samo zarządza repo na Linuksie i Windows. Nie zdziwiłbym się, gdyby na Linuksie działał ciut inaczej, choćby dlatego, że system udostępnia pewne ciekawe cechy (i grzechem byłoby ich nie użyć).
    
    "W Javie zrobili coś takiego jak JGit. Ale nie widzę sensu tego, bo to i tak zabija wydajność gita"
    
    Więc implementacja może być do kitu. No i nie ma sensu pisać w Javie czegoś, co będzie często odpalane (JVM to bardzo wydajna maszyna, tyle że ma duży narzut na start). Ale wyszliśmy od javowego IDE, gdzie kod connectora jest cały czas aktywny i dobranie się do jego metod nie jest dodatkowo obciążone. W eclipsie posiadanie natywnej implementacji to duży plus i jeśli koder nie spieprzy sprawy, to powinno działać sprawniej niż uruchamianie gita w nowych procesach (no i pewnie dawałoby większe możliwości).

31. Paweł Ciupak:
    01 Lip 2009, 01:41:34

    „Poza tym prawdopodobnie potrzebujesz nowych wersji bibliotek przy nowym kpdf.”
    
    E, moglibyście wybrać sobie lepszy przykład, niż od dawna nierozwijaną aplikację ;).

32. Hoppke:
    01 Lip 2009, 10:29:06

    Ostatni raz KDE widziałem parę lat temu, mea culpa :)

33. maciek:
    17 Paź 2009, 15:01:19

    Zbrodnią jest wykluczenie z tego zestawienia Fossila

Dodaj komentarz: