18 hozzászólás
Hmm… Valami backup egység nem lenne nálad jobb megoldás? Nem olcsók ezek a cuccok, de hosszú távon nagyon is kifizetődők… pl engem sokszor mentettek meg az idegösszeomlástól…
válasz
Hedge, az a kérdés hogy milyen módon frissül rajtuk az adat. Nos? 
Mert ha full automatikusan, és mondjuk on-the-fly felkerül rájuk minden, az nagyon istenes. (Kérdés mit ér meg, olyan sokat azért nem. Nem az a nagy baj, ha elvész x órányi cuccom, hanem hogy elvész x évnyi cuccom.)
Mert ha full automatikusan, és mondjuk on-the-fly felkerül rájuk minden, az nagyon istenes. (Kérdés mit ér meg, olyan sokat azért nem. Nem az a nagy baj, ha elvész x órányi cuccom, hanem hogy elvész x évnyi cuccom.)
Haszprus, volt olyan külső vinyóm, amin volt egy hatalmas Sync gomb, és adtak hozzá valami windowsos programot, ami a Sync gomb megnyomására a háttérben az egész belső vinyót lemirrorozta USB-n a külső vinyóra. Valami Freecom vagy milyen márka volt, már nem emlékszem rá, meg nyilván nem is tudtam kipróbálni, mert OS X-hez nem adtak drivert :-/ (Azóta mondjuk OS X-re lett Time Machine, úgyhogy már nem hiányzik). De szerintem neked valami ilyen lenne az ideális megoldás; asztali gépben akár folyamatosan bedugva is tarthatod a külső vinyót, kicsi az esélye, hogy USB-n keresztül független tápellátással is ugyanakkor döglik meg, mint a belső.
11)
Max Logan
Én tervezem a közeljövőben 2 db 250 GB-os HDD beszerzését és RAID-be kötését. Lesz 5 parcíció, az utolsó a backup. Oda tolom át, amit menteni kell (lesz kifejezetten olyan partíció, amire azon cuccok kerülnek, ami jó ha kéznél van, de nem sírok, ha eltűnik). Külső backup vinyó meg egy 250 GB-os notebook hdd lesz USB-s (és/vagy FireWire-ös) keretben. Ezen kívül minden megy ki DVD-re is 2 vagy 3 példányban.
A technikai része nem is gond, csak pénz kérdése. Ami ennél kérdésesebb egy normális backup szisztéma kidolgozása. Eddig arra gondoltam, hogy tematikusan dobálom át nap végén backup partícióra a dolgokat, majd onnan backup vinyóra. Ha megvan egy DVD-nyi anyag a backup vinyón, akkor az megy DVD-re is. Valószínűleg év-hónap-nap formában lesznek a könyvtárak és ha van már egy újabb DVD-nyi anyag, már pörköljük is.
Viszont ezt csak a munka jellegű dolgokra csinálnám (programok (forráskódok), tervek, doksik, levelezés, stb.), a képek, zenék külön állatfaj. Azoknak fent lesz tartva egy partíció, amin gyűjtögetve lesznek. Ha megértek mentésre (összejött egy DVD-nyi anyag pl. albumokból), akkor mennek DVD-re 2-3 példányban (ha megtartani nem akarom, de ha még meg akarok hallgatni valamit, akkor megy a nem mentendő anyagok közé).
Ezen kívül gondolkodom a teljes oprendszer heti vagy havi ghost-olásán, de ez nagy eséllyel csak backup vinyóra kerülne, DVD-re nem.
A technikai része nem is gond, csak pénz kérdése. Ami ennél kérdésesebb egy normális backup szisztéma kidolgozása. Eddig arra gondoltam, hogy tematikusan dobálom át nap végén backup partícióra a dolgokat, majd onnan backup vinyóra. Ha megvan egy DVD-nyi anyag a backup vinyón, akkor az megy DVD-re is. Valószínűleg év-hónap-nap formában lesznek a könyvtárak és ha van már egy újabb DVD-nyi anyag, már pörköljük is.
Viszont ezt csak a munka jellegű dolgokra csinálnám (programok (forráskódok), tervek, doksik, levelezés, stb.), a képek, zenék külön állatfaj. Azoknak fent lesz tartva egy partíció, amin gyűjtögetve lesznek. Ha megértek mentésre (összejött egy DVD-nyi anyag pl. albumokból), akkor mennek DVD-re 2-3 példányban (ha megtartani nem akarom, de ha még meg akarok hallgatni valamit, akkor megy a nem mentendő anyagok közé).
Ezen kívül gondolkodom a teljes oprendszer heti vagy havi ghost-olásán, de ez nagy eséllyel csak backup vinyóra kerülne, DVD-re nem.
Max Logan: allati termelekeny programozo lehetsz, ha a forraskodot mindig DVD-kre kell menteni 
Szvsz a forraskodja meg egy oprendszernek is elfer egynehany floppyn. Ehelyett erdemesebb egy SSD-n vagy akar pendrive-okon elmenteni, azok ha nincsenek surun hasznalva, evtizedekig is biztonsaggal taroljak az adatokat.
Persze ha ejjel-nappal videot / zenet vagsz es meg evek multan is szukseg lehet a nyersanyagra, akkor valoban jol johetnek a DVD-k meg X db backup vinyo.
Szvsz a forraskodja meg egy oprendszernek is elfer egynehany floppyn. Ehelyett erdemesebb egy SSD-n vagy akar pendrive-okon elmenteni, azok ha nincsenek surun hasznalva, evtizedekig is biztonsaggal taroljak az adatokat.Persze ha ejjel-nappal videot / zenet vagsz es meg evek multan is szukseg lehet a nyersanyagra, akkor valoban jol johetnek a DVD-k meg X db backup vinyo.
14)
Max Logan
NeoXon: mint írtam, nem csak forráskódok, hanem doksik (pl. árajánlat, szerződések, stb.), a teljes levelezés backup-ja, szóval a munka termékeit menteném ki napi lebontásban. Valamint pl. hobbi tevékenység termékei (SketchUP modellek), stb.
Haszprus: anno próbálkoztam SVN-nel, de értelmes, szájbarágós, alapoktól kezdős, magyar doksi nélkül nem igazán éreztem rá az ízére, avagy az értelmét látom, csak használni nem tudtam. Amit nem igazán értettem, hogy mit és miért és miért ott tárol le a fájlrendszerben; Windowsról van szó egyébként és egy nagy nehezen neten levadászott magyar doksi alapján telepítettem fel a szervert + TortoiseSVN-t.
Így maradt a minden nap kimentünk mindent elv. Ami bár rendundáns adattárolás, viszont a DVD nem túl drága.
Ui.: Valaki egy értelmes full alapoktól kezdős magyar SVN doksit nem tud? Tehát onnantól kellene, hogy induljon, hogy igényünk van a verziókezelésre, definiálja, hogy mi az, aztán mint megoldás vezesse be az SVN-t és magyarázza el, hogy mit, miért, hogyan.
Haszprus: anno próbálkoztam SVN-nel, de értelmes, szájbarágós, alapoktól kezdős, magyar doksi nélkül nem igazán éreztem rá az ízére, avagy az értelmét látom, csak használni nem tudtam. Amit nem igazán értettem, hogy mit és miért és miért ott tárol le a fájlrendszerben; Windowsról van szó egyébként és egy nagy nehezen neten levadászott magyar doksi alapján telepítettem fel a szervert + TortoiseSVN-t.
Így maradt a minden nap kimentünk mindent elv. Ami bár rendundáns adattárolás, viszont a DVD nem túl drága.
Ui.: Valaki egy értelmes full alapoktól kezdős magyar SVN doksit nem tud? Tehát onnantól kellene, hogy induljon, hogy igényünk van a verziókezelésre, definiálja, hogy mi az, aztán mint megoldás vezesse be az SVN-t és magyarázza el, hogy mit, miért, hogyan.
16)
Max Logan
mainframe: Bő fél évvel ezelőtt próbálkoztam SVN-nel. TSVN-nel nem volt gond, működött, használtam is. Csak nem igazán értettem, hogy a history-t file szinten miért úgy menti el ahogy. Valamint nem volt részletes leírásom arról, hogy gyakorlatban hogyan kell csinálni pl. azt, hogy van egy project, annak egy modulját (jól körülírható fájlok fizikailag más helyen a könyvtárszerkezetben) akarom kicsit átalakítani, hozzátenni fájlokat, és ezt hogyan tudom megcsinálni, hogy majdan tudjam egyesíteni az éles project-tel.
Szóval a lényegét értem, hogy mire jó a verziókezelés, csak gyakorlatban nem igazán tudom, hogy hogyan kell megvalósítani, amit akarok. Arra meg sem időm, sem kedvem, hogy kisakkozzam, hogy mit és hogyan kell.
Meg az sem teljesen tiszta, hogy hogyan tud több ember egy project-en dolgozni. Van pl. egy olyan file, ami alapja egy project-nek (valami alap osztály vagy közös lib fájl) és ezt b*sztatja két ember, más dolgokat ír át benne (de pl. ugyanazt a függvényt, vagy osztályt), hogy ebből hogyan lesz a végén egy olyan kód, amiben mindkét ember változtatásai benne vannak és a kettő funkcionalitása egyesül. Szóval az elméleti hátterét és a folyamatokat nem ismerem, ehhez nem találtam magyar leírást…
Anno SVN nekem végülis arra kellett volna, hogy: van egy élesített project, ami áll X db file-ból. Jön egy fejlesztési igény, változik több file is a már éles project-hez képest, majd a végén, amikor a DEV cucc működik, ne kelljen mindent file-t újra felmásolni az éles szerverre, hanem ki tudjam válogattatni SVN-nel, hogy mit kell nekem FTP-n feltölteni.
De ezen funkcionalitás miatt már nem kell SVN, mert kidolgoztam egy saját depolyment tool-t, amivel élesítem a project-et. Így ha valami változik, akkor új élesített csomagot kell létrehozni és mindent törölni az éles szerverről; mert a deployment tool pl. tömöríti a CSS kódot, a JS fájlokat, összevon PHP fájlokat, amiket tömörít is (lévén éles szerveren lévő kódot nem változtatunk, mert az nem egészséges…), stb.
Szóval, ami nekem hiányzik az a verziókezelési elmélet és ezt követően egy példákon keresztül bemutatott how to sorozat…
Szóval a lényegét értem, hogy mire jó a verziókezelés, csak gyakorlatban nem igazán tudom, hogy hogyan kell megvalósítani, amit akarok. Arra meg sem időm, sem kedvem, hogy kisakkozzam, hogy mit és hogyan kell.
Meg az sem teljesen tiszta, hogy hogyan tud több ember egy project-en dolgozni. Van pl. egy olyan file, ami alapja egy project-nek (valami alap osztály vagy közös lib fájl) és ezt b*sztatja két ember, más dolgokat ír át benne (de pl. ugyanazt a függvényt, vagy osztályt), hogy ebből hogyan lesz a végén egy olyan kód, amiben mindkét ember változtatásai benne vannak és a kettő funkcionalitása egyesül. Szóval az elméleti hátterét és a folyamatokat nem ismerem, ehhez nem találtam magyar leírást…
Anno SVN nekem végülis arra kellett volna, hogy: van egy élesített project, ami áll X db file-ból. Jön egy fejlesztési igény, változik több file is a már éles project-hez képest, majd a végén, amikor a DEV cucc működik, ne kelljen mindent file-t újra felmásolni az éles szerverre, hanem ki tudjam válogattatni SVN-nel, hogy mit kell nekem FTP-n feltölteni.
De ezen funkcionalitás miatt már nem kell SVN, mert kidolgoztam egy saját depolyment tool-t, amivel élesítem a project-et. Így ha valami változik, akkor új élesített csomagot kell létrehozni és mindent törölni az éles szerverről; mert a deployment tool pl. tömöríti a CSS kódot, a JS fájlokat, összevon PHP fájlokat, amiket tömörít is (lévén éles szerveren lévő kódot nem változtatunk, mert az nem egészséges…), stb.
Szóval, ami nekem hiányzik az a verziókezelési elmélet és ezt követően egy példákon keresztül bemutatott how to sorozat…
Van pl. egy olyan file, ami alapja egy project-nek (valami alap osztály vagy közös lib fájl) és ezt b*sztatja két ember, más dolgokat ír át benne (de pl. ugyanazt a függvényt, vagy osztályt), hogy ebből hogyan lesz a végén egy olyan kód, amiben mindkét ember változtatásai benne vannak és a kettő funkcionalitása egyesül.Az SVN a változtatásoakt úgy tárolja el, hogy egy 2-3 sornyi környezetet is eltárol a változtatásokkal együtt, ez alapján azonosítja be, hogy mit kell módosítani egy másik fejlesztő régebbi verziójú fáján, hogy az újat kapja. Ha két fejlesztő a fájl két olyan részét piszkálja, hogy a körülöttük lévő két-három sornyi
paddingrészek nem érnek össze, akkor fasza minden, mindkét változtatás két független revízióban mentésre kerül és kész. Ha összeérnek, akkor a második fejlesztőnél azt fogja jelezni az SVN, hogy
conflictvan, odaadja neked az eredeti fájlt (amiből kiindultak a módosításaid), odaadja a másik fejlesztő verzióját, meg odaadja az általad módosított változatot, aztán tessék, oldd fel a konfliktust magad. Épp ezért van egy olyan
szabályaz SVN-ben, hogy committálni csak akkor lehet, ha a legfrissebb revízión állsz, hogy a legfrissebb revízióra való frissítéskor mindig kijöjjenek a conflict szituációk. Szóval így. Az SVN-nek fogalma sincs arról, hogy mit jelent az, ami a fájlban van (szemantikailag), ő csak összefésüli a módosításokat, ha tudja; ha nem, akkor meg rád hagyja a piszkos munkát.
van egy élesített project, ami áll X db file-ból. Jön egy fejlesztési igény, változik több file is a már éles project-hez képest, majd a végén, amikor a DEV cucc működik, ne kelljen mindent file-t újra felmásolni az éles szerverre, hanem ki tudjam válogattatni SVN-nel, hogy mit kell nekem FTP-n feltölteni.Erre a legegyszerűbb megoldás az, hogy az éles verzió a szerveren egy SVN-ből checkoutolt változat, így ott csak azt mondod neki parancssorból, hogy
svn update, aztán az SVN szépen letölti a változásokat. A dolog abban az esetben nem működik, ha a távoli szerverre csak FTP vagy SSH hozzáférésed van; ilyenkor én azt szoktam, hogy a saját gépemen van az éles változatból egy mirror, arra nyomok egy svn update-et, majd rsync-kel szinkronizálom a távoli változatot a saját gépemen lévő mirrorhoz.
és ez csak a kernel.
