pld cvs -> hg (dawno temu jako cvs -> svn)

Tomasz Pala gotar w polanet.pl
Sob, 7 Cze 2008, 14:57:55 CEST


On Sat, Jun 07, 2008 at 11:59:37 +0200, Bartosz Taudul wrote:

> Z punktu widzenia pracy nad pakietem rozdzielenie speca od źródeł nie ma
> sensu.

Right.
Ale z punktu widzenia dystrybucji potrzebny jest hurtowy dostęp do
wszystkich speców (z pominięciem źródeł - zassanie, commitowanie i
cvsupowanie całego SPECS nie jest niczym strasznym, pobieraniem SOURCES
można by postraszyć dzieci).

> Daruję sobie wymienianie zalet trzymania ich razem. Pytanie brzmi
> - czy wynikające z wieloletniego używania CVS-a przyzwyczajenie do
> grepowania wszystkich speców rzeczywiście jest dużo istotniejsze od
> korzyści wynikających z atomowych commitów speców i źródeł? Od biedy da

Nie wiem - pracuję na pojedynczych pakietach, denerwuje mnie CVS
czasami, ale nie na tyle, abym w ogóle myślał o zmienianiu.


Aha - już chyba kiedyś wspominałem, ale przypomnę: gdy kiedyś miałem
ochotę jednocześnie pracować na różnych branchach, to miałem osobny
katalog SPECS-Ac (nazwa zmieniona po pierwszym csv co, wtedy już nie ma
znaczenia). Trick jest bardzo prosty i polega na:

echo TAC-branch > SPECS-Ac/CVS/Tag

od tej pory wszystkie operacje odbywały się na tym branchu, a na HEAD
mogłem robić w normalnym katalogu SPECS. Tej samej metody można używać
do tagów oraz dat.

Co można dzięki temu osiągnąć poza grepowaniem? Np. teraz w opisany
wyżej sposób ściągnąłem sobie całe DEVEL - 414 speców, w 10 sekund.
Od razu widzę, że 313 z nich jest jeszcze z 2007 roku, czyli z pewnością
prace są zarzucone. Więcej - 9 speców datuje się na styczeń-luty 1999!

> jak w chwili obecnej obchodzimy krapowatość CVS-a używając skryptu
> builder.

Jakby nie patrzeć, to większość źródeł (objętościowo, liczbowo raczej
nie) tak czy inaczej jest w distfiles, więc bez buildera się nie
obejdzie.

-- 
Tomasz Pala <gotar w pld-linux.org>


Więcej informacji o liście dyskusyjnej pld-devel-pl