Bye-bye, CVS

Miam na tyle dość CVS, że postanowiłem przenieść moje Jabberowe projekty
do Subversion. Okazało się to łatwiejsze niż przypuszczałem. Na JabberStudio
jest zainstalowany SVN, skonfigurowany svnserve, a nawet jakiś
ViewCVS do tego.

Wczoraj wieczorem przemigrowałem repo PyXMPP. Dodałem skrypt do generacji
ChangeLog (tym razem nie po stronie serwera) oraz automatykę do generowania
snapshotów — dla tych co uparcie bronią się przez SVN, a chcieli by
spróbować świeżego PyXMPP czy CJC.

Następne w kolejce jest oczywiście CJC, no i może Transport GG. Zobaczymy
co z tego wyniknie.

19 uwag do wpisu “Bye-bye, CVS

  1. adamg:
    – brak możliwości normalnej modyfikacji struktury projektu: zmiany nazwy plików czy przenoszenia ich między katalogami.
    – konieczność transmisji całego pliku przy commicie nawet minimalnej zmianie.
    – brak możliwości zrobienia diffa ostatnich zmian bez kontaktu z repo i tworzenie takiego diffa spowolnione przez konieczność komunikacji z repo (znów transmisja całych plików)
    – brak atomowości commitów. W CVS commit dotyczący wielu plików to właściwie masa osobnych commitów powiązanych jedynie czasem i komentarzem.
    – pomieszanie meta informacji o zawartości repo z samą zawartością (pliki .cvsignore)
    – brak bezpiecznego protokołu dostępu do repo nie wymagającego kont shellowych na serwerze
    – kiepska obsługa atrybutów takich jak "wykonywalny"
    – kiepska obsługa plików binarnych (nie dość że nie są robione żadne diffy i zawsze ciągnięta jest całość, to jak się zapomni oznaczyć plik jako binarny, to może on zostać uszkodzony przy commicie).
    itd. itp.

    Polubienie

  2. Najgorsze to powolne cvs2svn… repo cvs.pld-linux.org konwertuje się jak zeznaje ps od: Oct24 234:09 i jest dopiero przy 52280 na 197109 rev. Cały proces konwersji drwa już jakieś 2 tygodnie ze względu na to, że gdy mamy błędy w pliku RCS to narzędzie się dopiero wykrzaczy przy tworzeniu konretnej rev czyli … na końcu :/
    Do tego obecnie wygląda to tak (FSFS gdyby ktoś pytał):
    $ du -sh cvsroot-pld/ new-subversion/
    1,3G cvsroot-pld/
    11G new-subversion/
    Mimo wszystko działam dalej 8)

    Polubienie

  3. Jajcuś, a czy te uwagi odnośnie cvs nie są trochę, no, naciągane?

    Pierwszy – to fakt, brak cvs mv bywa czasem bolący, ale czy aż tak często?

    Kolejne dwa punkty są w gruncie rzeczy pomijalne – aż tak Ci przeszkadza przesyłanie całych plików w Twoich projektach?

    Co do pozostałych punktów (poza tym dotyczącym logowania), czy aż tak Ci to przeszkadzało, tak często brakowało Ci takiej funkcjonalności, że przeniosłeś się na SVN?

    I nie, nie chcę flejma. Po prostu zastanawiam się nad fenomenem Subversion. A to chyba dlatego, że w głębi duszy jestem przeciwnikiem zmian, a co za tym idzie wymyślaniem i stosowaniem różnych workaroundów miast zamiany narzędzia na inne, lepsze.

    Polubienie

  4. To przesyłanie całych plików _bardzo_ boli, szczególnie gdy serwer jest w ameryce a ja mam wiele małych poprawek.
    Przed chwilą znowu się wkurzałem na CVS w którym sprzątałem. W każdym katalogu musiałem robić "rm lista plików", "cvs rm lista plików" (nie mogłem dać "cvs rm *", bo podczas "cvs rm" plików ma już nie być). No i za każdym "cvs rm" musiałem czekać aż on się z repo połączy i coś tam załatwi, mimo że i tak zmiany zostały commitnięte dopiero gdy dałem "cvs commit" na końcu. To niby duperele, ale wkurzające.
    A pozostałe punkty też w jakimś stopniu były dla mnie istotne. Chociażby gdy miałem komuś z zewnątrz udostępniać repo rw na swojej maszynie. CVS nie daje żadnej możliwości która by mnie satysfakcjonowała (pod względem bezpieczeństwa i wygody, w tej kolejności).
    No i przekonuje mnie też przemyślana architektura Subversion. Zobacz ile już jest do tego rozszerzeń, interfejsów itp. Może nawet więcej niż do CVS, a przecież to projekt dużo młodszy i mniej popularny — najwyraźniej do SVN dużo łatwiej takie rzeczy zrobić (w końcu użyte są standardowe protokoły (WebDAV) i dostępne są biblioteki dla C i Pythona). A ja często miewam potrzebę integracji różnych systemów i rozwiązań, więc wolę takie które wszelką integrację ułatwiają.

    Polubienie

  5. jajcus: niestety, wg. ludzi z #cvs2svn skrypt zawsze robi od początku
    adamg: nie, to tylko tak testowo, by można było zobaczyć i się pobawić (ew. gdy pld-ludkowie powiedzą tak, to nastąpi konwersja i rm -rf cvs, no dobrze… kopia zostanie
    jajcus: cvs rm -f *?

    Polubienie

  6. Mnie brak mv zabolał w CVS parę razy. A także to, że nie da się łątwo zrobić changelogu. I jeszcze to, że proste obejrzenie zmian, jakie się zrobiło w working copy zakrawa na ból tyłka.
    Narzędzia nie powinny utrudniać życia.

    Polubienie

Co o tym sądzisz?