-
Data: 2010-10-06 11:00:30
Temat: Re: System kontroli wersji.
Od: Sebastian Kaliszewski <s...@r...this.informa.and.that.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]Stachu 'Dozzie' K. wrote:
> On 2010-10-05, Przemysław Osmański <p...@o...eu> wrote:
>> W dniu 2010-10-05 19:58, Bodek pisze:
>
>>> Patrz wyżej. Nie wyobrażam sobie (już), żeby zmiany szły na serwer od
>>> razu podczas commita. Zdarza mi się czasem popełniać dosyć oczywiste
>>> błędy i bardzo sobie cenię możliwość skorygowania lokalnej historii
>>> repozytorium, tak żeby o moich pomyłkach nikt się nigdy nie
>>> dowiedział. Co więcej, początkowe implementacje nowych rzeczy mają do
>>> siebie to, że są robione trochę na czuja. Często po jakimś czasie
>>> (godzina, pół dnia, dwa dni), w miarę zgłębiania problemu wiedza na
>>> jego temat poszerza się o tyle, że tą początkową implementację chciało
>>> by się zmienić. Git daje mi taką możliwość, SVN nie.
>> A mi taką możliwość daje środowisko programistyczne. Kontrola wersji,
>> też zintegrowana ze środowiskiem, jest raczej dodatkiem do niego a nie
>> narzędziem które ma za nie odwalić połowę roboty. Chyba że używasz
>> notatnika lub czegoś jego pokroju.
>
> Przepraszam, czy ja dobrze rozumiem? Masz IDE, które oprócz integracji
> z systemem kontroli wersji ma własny system kontroli wersji?
>
> Zaznaczam że ja się od IDE trzymam z daleka[*] i po prostu chcę wiedzieć
> czy ja czegoś o tym typie narzędzi nie wiem.
>
> [*] Inna sprawa że nie piszę nic co ma więcej niż kilka KLOC-ów,
Czyli masz mocno nietypową jak na programistę robotę. A więc należy się
spodziewać i nietypowych wymagań.
za to
> często piszę w różnych językach i uczenie się osobnego IDE dla każdego
> języka to albo by był overkill, albo by mi było niewygodnie w każdym
> ze środowisk.
Jest parę IDE wielojęzycznych...
>
>>> Poza szybkością, gotowością rozwiązania, automatyzacją i możliwością
>>> poprawienia błędu u źródła, a nie w późniejszym commicie. Ale poza tym
>>> to zupełnie nic.
>> Po tym co tutaj czytam i moich testach gita, wydaje mi się, że zagorzali
>> jego obrońcy używają go tylko dlatego że jest taka moda.
>
> Nieprawda. Wcześniej używałem głównie Subversion. Gita zacząłem używać,
> bo to był jedyny znany mi[*] system kontroli wersji, który miał
> sensownie rozwiązany interfejs do dwukierunkowej komunikacji
> z Subversion (potrzebne mi były operacje przy braku dostępu do serwera
> SVN). A potem przesiadłem się całkiem. Nie dlatego że moda, tylko
> dlatego że było mi wygodniej.
Patrz wyżej [typowość wymagań].
>
> [*] Potem się okazało że mogłem użyć SVK. Ale na chwilę wyboru nie
> znałem go.
>
>> Szkoda że nie
>> dociera do nich, że SVN jest wystarczający nawet dla dużych, ale
>> lokalnych, projektów.
>
> Do momentu gdy trzeba więcej pracować z gałęziami. Póki masz bardzo
> prosty workflow, to SVN wystarczy.
>
>> GIT najczęściej jest przerostem formy nad treścią.
>
> Ę? Znaczy w którym miejscu? Bo podstawowy workflow jest z grubsza taki
> sam co SVN, tylko więcej opcji masz na wierzchu.
GIT łatwiej pozwala na zrobienie kompletnego burdelu, pogubienie połowy
historii itd. W przypadku małego (w tym zdegenerowanego do 1 os) zespółu
to nie ma problemu, ale w przypadku dużych zespołów owszem -- i w
jednych lepiej sprawdzi się git (projekty typu linux, mozilla, itd) a w
inncyh svn ("centralnie sterowane")
>
>> Z tym że ja nie uważam SVNa za jedyne cudo warte używania i nie staram
>> się nikomu go narzucać/
>
pzdr
\sK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)
Następne wpisy z tego wątku
- 06.10.10 10:55 Sebastian Kaliszewski
- 06.10.10 11:18 Patryk Włos
- 06.10.10 11:54 Patryk Włos
- 06.10.10 16:48 Andrzej W.
- 06.10.10 18:17 Sebastian Biały
- 06.10.10 18:31 Sebastian Biały
- 06.10.10 18:35 Sebastian Biały
- 06.10.10 18:57 Andrzej W.
- 06.10.10 19:04 Sebastian Biały
- 06.10.10 19:07 Andrzej W.
- 06.10.10 19:15 Norbert
- 06.10.10 22:42 Michoo
- 07.10.10 08:16 Tomek[TK]
- 07.10.10 10:10 Andrzej W.
- 10.10.10 06:15 Miron (Asha) Kitkowsk
Najnowsze wątki z tej grupy
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
Najnowsze wątki
- 2025-01-26 Trump-2 JUŻ bardzo łaskawy [1_500 ułaskawień skazanych za Bidena za "Kawkę na Kapitolu"]
- 2025-01-26 Brak bolca ochronnego ładowarki oznacza pożar
- 2025-01-24 Elektryfikacja w ODWROCIE
- 2025-01-25 AMS spalony szybkim zasilaczem USB
- 2025-01-24 stalowe bezpieczniki
- 2025-01-23 Zenek Kapelinder - ?
- 2025-01-25 Błonie => Sales Specialist <=
- 2025-01-25 Lublin => iOS Developer (Swift) <=
- 2025-01-24 Warszawa => Java Developer <=
- 2025-01-24 Białystok => iOS Developer (Swift experience) <=
- 2025-01-24 Warszawa => Programista Full Stack (.Net Core) <=
- 2025-01-24 Warszawa => System Architect (background deweloperski w Java) <=
- 2025-01-24 Lublin => Delphi Programmer <=
- 2025-01-24 Kraków => Key Account Manager <=
- 2025-01-24 Lublin => Programista Delphi <=