PISKVOR: Mam skripty na to, co je vyhodne skriptovat. Ale deployovaci kolecko znamena "udelat balicek, nahrat tar.gz na server, nahrat ebuild na server" (jeden skript na jednom pocitaci) a "dat update;emerge -DuN world; /etc/init.d/produkt restart" na produkci (druhy skript na druhem pocitaci).

Vzhledem k tomu, ze ne vzdy se restart hodi a projiti zavislosti nejakou dobu trva a kopirovani balicku taky, navic casto zmena muze zasahnout vic balicku (system jich ma par desitek) a je dobre ji publikovat naraz a zaroven to taky lidi pouzivaji, tak neni dobre mit svazano nasazovani s vyvojem. Takze si vesele programuju, kdy se to hodi me a nasazuju, kdy se to hodi zakaznikum.

Ten git na produkci je naprosto nesvazany s jinymi repozitari a neni duvod je provazovat, v normalnim provozu jsou commity pouze typu "upstream verze", tyhle divokosti se deji jen zridka. A obcas zasahuji povicero balicku a je zajimavy az konecny vysledek a ne co vsechno zakaznik chtel vyzkouset a pak zavrhnul.

GILHAD: A na to nemas skript, kterej to deployovaci kolecko udela automagicky, kdyz commitnes neco na gitu do vetve "master" (nebo "release", nebo co tam mas)? Ja myslel, ze to uz je dneska skoro samozrejmost. Aspon teda ze tu nepadlo F-word (to na tri pismenka).

vyzkoušim tenhle script http://code.google.com/p/git-sync/
sice mi ty nový soubory(na produkci) nevypíše, ale rovnou jimi zpětně updatne ty z dev. verze, ale s trochou snahy by se to dalo přiohnout.

Jinak jednu git repository mám v té dev. verzi projektu. Používám občas před nějakými úpravami, kdy se bojim že něco rozbiju a budu muset rychle vrátit. Při syncu se do prod. verze kopíruje i tenhle .git adresář/repozitář, takže nějaký porovnávání mězi nimi asi nepřipadá v úvahu, když jsou stejný(?)

Je pravda že git používám dost povrchně, možná že to co potřebuju zvládá levou zadní. Budu ho muset trochu nadrtit.

Ja to delam tak, ze mam i na te produkcni nahozeny git (s prislusnyma .gitignore) a po nasazeni vzdy commitnu zmeny, ze "upstream x.y.z". A pred nasazovanim git status, git diff, a hned je videt, kam a jak se sahalo (a snadno se to copy+paste prenese na ten dev, nebo kamkoli jinam)

(Jo, v nekterych pripadech fakt saham na produkcni, zvlast, kdyz si nekdo vzpomene, ze nutne prave ted (pul hodiny pred navstevou zakaznika, kteremu to chce ukazat) potrebuje preformulovat nejake texty nebo prebarvit nejake barvy ve webovkach a ze se na to hned koukne a rekne co jeste dal ... tam tezko neco rozhodim prilis a delat cele kolecko s vytvarenim balicku a nasazenim, zvlast, kdyz vzapeti rekne, ze ta zelena je moc zelena a ze tam radsi teda mam dat modrou, aby nakonec usoudil, ze puvodni hneda asi byla fakt lepsi, jen by mohla byt trochu svetlejsi ... to by bylo nesmyslnych balicku az hruza ...)

Tak jsem vytvořil nový image a nainstaloval/nakonfiguroval těch pár služeb znovu, zas tak moc práce to nakonec nebylo :)

A poprosil bych o help ještě s jednou věcí: mám na jednom serveru produkční a testovací verzi jednoho projektu + script, který rsyncuje soubory z dev verze na produkční. Už se mi stalo, a obávám se že v budoucnu stane znovu, že byly na prod. verzi nějaké nové úpravy, které někdo (třeba i já:) udělal rovnou na této prod. verzi, ale ne na devel. Při syncu by to pak nedělalo dobrotu.

Vím, že s rsyncem můžu updatovat jen starší/na prod. verzi nezměněné soubory. Ale to by pak mohl vzniknout maglajz a na dev verzi by se tak úpravy z prod. stejně nedostaly. Takže bych chtěl nějak v rámci toho synchronizačního sciptu zjistit, že prod. verze obsahuje nověji modifikovaný soubory. Nejlépe teda rovnou ty soubory i rovnou vypsat, abych to mohl zkontrolovat a případně zkopčit na dev. ručně.

RATTKIN: Divný; ještě je otázka, jestlis tam neměl nějaký exotický FS - já takhle zmenšoval vfat, ntfs, ext[34], i o třeba dvacet procent, a bez problému (musí tam být pochopitelně adekvátní volný místo).

Jinak pokud máš image a tohle ti nejde, namountoval bych to rw do loopu a pustil na to gparted, ten partitions zmenšuje už úplně bez problémů.

PISKVOR: Zkouše jsem to před 3 měsíce v poslední stable clonezilla live, zkoušel jsem save disk disk - restore disk, i partition -> partition. nic mi nešlo. V reklamaci vyměnili 250g disk WD za jiného výrobce, který byl o půl mega menší, strašnej wopruz

PISKVOR: A teda bacha, Clonezilla != Clonezilla Live...

RATTKIN: Ne? Já mám dojem, že už nejmíň dva roky umí - resp. pokud děláš restore-to-disk, tak na menší disk všechny obnovovaný partitions proporcionálně zmenší. Nevím, jestli to umí i v módu restore-single-partition...

PISKVOR: s clonezillou jsem vždycky měl problém, když jsem chtěl jí na menší disk, neumí resize partition (nebo možná jo, ale po nějaký super konfiguraci)

SYNTAX_TERROR, RATTKIN: Kdysi jsem to takhle řešil pomocí Clonezilly Live (nabootované uvnitř virtuálu)- starý VM zazálohovat na hosta, zálohu obnovit na menší virtuální disk. Zdlouhavé, leč funkční.

SYNTAX_TERROR: taky by se dala kopírovat patition na novou menší partition přes gparted nebo něco podobného

LUDO: tak to mi prave pripada, ze to tim byt muze. Aspon ja teda mam porad stejnej kurzor, at uz sem teba v unity, xfce nebo gnome.

PUNKREASS: temou to neni, problem sa prenasa aj medzi inymi prostrediami (JWM, Openbox, ...)

LUDO: na mne to neadresuj, ja ti neporadim, ja sem lama:] Jediny, co bych tak ja dokazal vyzkouset, je testnout jinej kurzor a nebo ho nacitat z ~/.icons

PUNKREASS: http://pastebin.com/TXzqfk5W

LUDO: spis ti nekdo poradi, kdyz sem obsah toho xorg.conf das.

Nejaky navrh jak riesit neviditelny kurzor? akcie mysi funguju spravne, len nevidim kurzor

Hybridne grafiky na laptope Intel/AMD, po instalacii FGLRX z repozitarov a spusteni "aticonfig --initial" (vytvori /etc/X11/xorg.conf) sa stal kurzor neviditelnym. V OpenGL aplikaciach (hry) ho vidim.

Ked zmazem xorg.conf tak je znova viditelny, ale zas nefunguje spravne driver - bezi na opensourcovych.

Pouzivam Debian Jessie, verzia drivera z repozitarov je fglrx-driver (1:14.9+ga14.201-2). Prostredie je KDE (kurzor nevidim ani po nabehnuti kdm). Kernel 3.16.0-4-amd64.