Dotaz: svn: post-commit hook (rychlost)

[j3nda]

Příloha:

• post-commit.sh (1597 bytů)

zdravim,

rad bych se zeptal nekoho zkusenejsiho a znaleho svn (post-commit hook), prip. i jinych hooku.

mam nastaveny svn server, ktery resi veci pres https (webdav); toto tak byt musi, potrebuji https. na serveru bude nekolik (rekneme stovek) repozitaru. kazdy repozitar ma svuj (stejny) hook adresar se stejnymi skripty.

mam napsany jednoduchy post-commit hook, ktery resi nasledujici 2x veci: - zivou kopii z repozitare na web - nastaveni svn:writable (adresare pro zapis on|off) - nastaveni svn:cleanable (adresare, ktery se po commitu vycisti)

zajima me rychlost tohoto skriptu. je to napsano v bashi. pokud se v teto rovine nekdo pohybuje, pisnete nazor, prip. nejake vylepseni, cim by se to dalo zrychlit.

mam totiz takove divne mrazeni, ze to bude pomale (kdyz jsem to resil s kolegou jarkem dvorackem z ataxa, tak jsme to testovali na freebsd (resp. on to testoval) na asi 11k souborech a podobne adresarich. 1. pruchod trval < 3s a dalsi uz byly rychlejsi

zrychlim to, kdyz se shell -> (prepise) -> do pythonu? anebo jineho jazyka? v jake mire se to zrychli, kdyz to prepisu do cecka?

diky za info. soubor je zde v priloze. j3

Odpovědi

[j3nda]

ja blbec vlozil tu prilohu i s heslem [jeste ze je svnserve jen na localhostu a heslo jsem samozrejme ihned zmenil] -- jen pro info pro stouravce.

[cronin]

mam totiz takove divne mrazeni, ze to bude pomale

Takze je to pomale, alebo nie? Ak je vykonnost dostatocna, riesis neexistujuci problem. Prepisovat 50 riadkov zdrojoveho kodu (t.j. excelentne strucne riesenie) do 500 riadkov potencialne rychlejsieho C kodu bez realneho dovodu je dobre iba ak z akademickych dovodov. Treba si uvedomit, ze N-nasobok poctu riadkov zdrojoveho kodu zo sebou nesie N-nasobne riziko chyby v kode. Nepozeral som co vlastne ten skript robi, ale v zasade vidim dve mozne priciny "pomalosti":

1) IO operacie. V tomto pripade je rychlost vykonavania samotnej riadiacej rutiny, t.j. post-commit hooku irelevantna, a zrychlit treba IO operacie samotne.

2) Neefektivny algoritmus riadiacej rutiny, napr. viacnasobne ziskavanie nejakej informacie ci suboru. V tomto pripade treba vylepsit algoritmus, napr. vyhnut sa opatovnemu ziskavaniu udajov. V tomto pripade opat nezalezi na implementujucom jazyku; opat vitazi program s jednoduchsim (kratsim) zapisom.

Jedna moznost, kedy by mohol byt shellovy skript na tom zle, je spustanie velkeho poctu procesov; napr. ked bude pre kazdy z tych 11k suborov spustat nejaky externy program, aby ho spracoval. V tomto pripade ale s vysokou pravdepodobnostou pojde problem riesit davkovym spracovanim, t.j. v zasade spustenim externeho programu naraz pre viacero suborov; vacsina unixovych toolov toto umoznuje, find a xargs su dobri pomocnici.

Nakoniec -- alebo skor na zaciatok -- aky "biznis" problem vlastne riesis? Existuje viacero hotovych rieseni na publikovanie SVN repozitarov cez web. I ked na druhej strane, Tvoj problem moze byt unikatny a teda moze vyzadovat unikatne riesenie. Sam som pomocou post-commit hookov naprogramoval v shelli uz dve continuous integration riesenia; a boli to stovky az tisice riadkov shellovych skriptov.

[j3nda]

timto jsi me premluvil, ze resim (zatim teoretickou) kravinu.

jedna se radove o do 100projektu a kazdy rekneme do 200MB dat (txt i bin). IO operace prozatim resit nebudu (jasne, rychlejsi hdd, prip hdparm).

ohledne prepisovani to vyresim logovanim, aby se dalo zjistit, zda to bude vykonostne mimo a ma smysl to resit.

s post-commit hookem prichazim do styku prvne, tak jsem se chtel jen zeptat co to snese nekoho znalejsiho.

(ano: resim unikatni problem sity na miru devel stroje, kde se tvori weby s naslednym publikovanim na web).

dik za info.

[cronin]

s post-commit hookem prichazim do styku prvne, tak jsem se chtel jen zeptat co to

Takze par mojich rad:

- Pozor na nastavenie prostredia. Odporucam vsetko dolezite si nastavit v skripte, vratane takych "nepodstatnych drobnosti" ako je PATH ci pracovny adresar, ktory je defaultne /. Pozor na pristupove prava, post-commit hook je samozrejme spustany obsluhujucim Apacom.

- Nepisat ziadne skripty priamo do suboru post-commit. Lepsie je vytvorit samostatny skript, a ten len z post commit hooku volat. Tak je jeden skript pouzitelny pre viacero repozitarov, ak sa vhodne parametrizuje.

- Prikaz 'svn commit' nevrati, pokial sa post-commit hook nevykona, co je vacsinou silne neziaduce. Preto treba 1) volat externy skript z post-commit hooku na pozadi, a zaroven 2) presmerovat stdout aj stderr "niekde"; mozno do /dev/null, lepsie do nejakeho vlastneho logovacieho suboru.

- Tym prichadzame k problemu, co sa stane, ak dojde druhy commit a teda aj druhe spustnie post-commit hooku este predtym, ako skoncila obsluha toho predchadzajuceho. Zabezpecenie reentrantnosti skriptu vratane spravneho pouzitia externych zdrojov ako su docastne subory ci pripadna vhodnu serializacia uloh su celkom zaujimave programatorske cvicenia.

[j3nda]

zkusim si to vzit k srdci a promyslet jak to bude. s tim spoustenim na pozadi me to nenapadlo. myslel jsem, ze kazdy 1x commit spousti 1x post-commit hook proces.

mam to ted udelane pres sudo, pze potrebuji jinou skupinu, tj.

/usr/bin/sudo -u fv.cz /home/www/fv.cz/_devel.svn/hooks/post-commit.sh "$1" "$2"

post-commit.sh jsem prikladal. v .sh si nastavuji vsechno, s tim presmerovanim vystupu to musim doresit. a s tou

>Zabezpecenie reentrantnosti skriptu

je mozne to vyresit pomoci zamku? docasne soubory vytvaret nechci (nemam ted potrebu). pokud bys to mohl rozvest budu vdecny.