Od jakie­goś czasu na listach PLD toczy się dys­ku­sja na temat zmiany układu repo­zy­to­rium. mma­zur ogło­sił nie­dawno testowe wdro­że­nie układu podob­nego do uży­wa­nego przez Por­tage. Mam nadzieję, że to pierw­szy krok na dro­dze do zmiany samego sys­temu wer­sjo­no­wa­nia kodu. A ma co śledzić, bo — wbrew pozo­rom — dys­try­bu­cja to dzie­siątki tysięcy pli­ków, nad któ­rymi trzeba jakoś zapanować.

CVS

Obec­nie do zarzą­dza­nia repo­zy­to­rium uży­wamy CVS. Ma swoje wady i zalety. Przede wszyst­kim można w nim wiele rze­czy auto­ma­ty­zo­wać, choćby ze względu na to, że pliki w repo­zy­to­rium mają swoje prze­ło­że­nie 1:1 na fizyczne pliki na dysku. Plik foo.spec ma wszyst­kie swoje dane w pliku foo.spec,v i można go sobie ręcz­nie bac­ku­po­wać, edy­to­wać albo zmie­nić mu nazwę. No wła­śnie, CVS ma kilka wad:

  • Nie ma moż­li­wo­ści prze­nie­sie­nia cze­go­kol­wiek w repo­zy­to­rium. Można usu­nąć plik i dodać go pod nową nazwą, ale w tym momen­cie tra­cimy jaką­kol­wiek histo­rię. Jedyna opcja to fizyczna zmiana nazwy pliku kon­troli wer­sji przez osobę z upraw­nie­niami admi­ni­stra­tora na serwerze.
  • Gałę­zie i tagi są przy­wią­zane do poszcze­gól­nych pli­ków kopio­wa­nie, sca­la­nie i prze­no­sze­nie pli­ków pomię­dzy gałę­ziami to praw­dziwy wrzód na dupie.
  • Z powyż­szego powodu, praca na kilku gałę­ziach jed­no­cze­śnie jest bar­dzo męcząca. Każdą gałąź trzeba pobrać z repo­zy­to­rium do osob­nego kata­logu. Każdy nowy plik odpo­wied­nio ozna­czyć, bo w prze­ciwym wypadku trafi w naj­mniej pożą­dane miej­sce. Do tego musimy spie­rać się z ser­we­rem o to, że wiemy, że plik o iden­tycz­nej nazwie już ist­nieje na innej gałęzi, ale nie ma nic wspól­nego z naszym.
  • Nie ist­nieją zestawy zmian, każda zmiana w repo­zy­to­rium jest poje­dyn­czą ope­ra­cją i nie ma po niej śladu w żadnym pliku poza aktu­al­nie modyfikowanymi.

Mercurial

Świe­żutka zabawka, łatwo roz­wi­jalna, ale jesz­cze nie speł­nia ocze­ki­wań dużej dystrybucji:

  • Każda kopia robo­cza jest peł­nym odbi­ciem lustrza­nym głów­nego repo­zy­to­rium. Nie ma moż­li­wo­ści pobra­nia jed­nego pliku, doko­na­nia w nim zmian i wysła­nia z powrotem.
  • Roz­bi­cie na rewi­zje i kody zesta­wów zmian jest bar­dzo nie­in­tu­icyjne ze względu na fakt, że tylko kod szes­nast­kowy jest unikalny.
  • Zaśmieca kopię robo­czą, two­rząc w niej kata­logi z meta­da­nymi, co utrud­nia pracę z narzą­dziami ope­ru­ją­cymi na pli­kach rekur­syw­nie (diff, find, grep).

GIT

Roz­pro­szony sys­tem kon­troli wer­sji zapro­jek­to­wany przez Linusa Torvaldsa. Nada­wałby się świet­nie, gdyby nie to, że ma intu­icyj­ność składni zbli­żoną do Emacsa. W związku z tym, nikt nie zmusi dewe­lo­pe­rów, żeby z dnia na dzień nauczyli się nowego narzę­dzia i prze­pi­sali wszyst­kie swoje skrypty. Zwłasz­cza, że z opcji pracy offline sko­rzy­sta góra kilka osób (w przy­padku dys­try­bu­cji, ciężko bez dostępu do sieci zbu­do­wać jaki­kol­wiek pakiet).

Subversion

Narzę­dzie spraw­dzone, ofe­ruje to samo, co CVS, jed­no­cze­śnie popra­wia­jąc jego nie­do­cią­gnię­cia. Nie ofe­ruje pracy na roz­pro­szo­nych kopiach repo­zy­to­rium. Ma za to jedną wadę Mercuriala:

  • Zaśmieca kopię robo­czą, two­rząc w niej kata­logi z metadanymi.
  • Kod pobrany z repo­zy­to­rium zaj­muje dwa razy wię­cej miej­sca niż powi­nien, bo trzy­mana jest lokalna kopia pliku (co pozwala na czę­ściową pracę offline).

Subversion + SVK

Wyobraź­cie sobie Sub­ver­sion, ale bez wspo­mnia­nych pro­ble­mów. Z peł­nym wspar­ciem dla pracy offline. To wła­śnie jest SVK — pełni rolę klienta Sub­ver­sion, zarzą­dza­jąc jed­no­cze­śnie kopią robo­czą i klo­nami repo­zy­to­rium. Kopie robo­cze nie są wzbo­ga­cane o żadne magiczne kata­logi z meta­da­nymi, nie mają narzutu w postaci trzy­ma­nia kopii pli­ków, a do tego sys­tem potrafi śledzić lokalne sca­le­nia i auto­ma­tycz­nie pod­po­wiada komen­tarz przy upy­cha­niu swo­ich zmian z powro­tem do głów­nego repo­zy­to­rium Subversion.

Roz­wią­za­nie nie­mal ide­alne — miło­śnicy GIT mają swoje ulu­bione funk­cje, a reszta może uży­wać tra­dy­cyj­nego klienta Sub­ver­sion. Bez żadnej magii shellowej.

Review Board

A skoro już mowa o Sub­ver­sion, to kilka dni temu chipX86 ogło­sił pro­jekt, który stwo­rzyli wewnętrz­nie na potrzeby VMware. Review Board, bo tak się nazywa, to apli­ka­cja Django, która pozwala wygod­nie prze­cho­wy­wać nad­sy­łane łatki. Na listach PLD poja­wia się ich sporo i czę­sto giną w cze­lu­ściach skrzy­nek pocz­to­wych. Coś takiego z pew­no­ścią by nam się przy­dało — miej­sce, gdzie każdy z uczest­ni­ków listy może zapro­po­no­wać swoje zmiany i otrzy­mać komen­ta­rze jesz­cze przed włą­cze­niem ich do samej dys­try­bu­cji. Miej­sce, gdzie łatki nie giną.