[quote:4770eef4b5="Panther"]Igen, elolvastam. Csak épp ha nekem jó az, ami van, akkor miért váltanák?
Ezért:[quote:4770eef4b5="suti"]az ember addig használ cvs-t míg ki nem próbálja az svn-t ...
Alapvetően nekem is jó volt a CVS, amíg azt használtam, de ugye file átnevezésekor a history "kettétörik", és a per file reviziók is okoztak olykor bosszúságot, ha később több file-t is módosító commitot akartam egyben viszontlátni... De ezekkel a korlátozásokkal egész jól együtt lehetett élni.
Aztán jött egyik kolléga, h vessek én is egy pillantást a Subversionre... Nem tartott túl sokáig, amíg az egész tanszék (az RCS írója vezeti...) átállt CVS-ről Subversionre, és csodálkoznak, h hogyan tudtak egyáltalán annyi ideig meglenni a CVS-sel.
[quote:4770eef4b5="Panther"]Ráadásul Sourceforge.net-en csak CVS van, innentől azt hiszem, trivi, hogy svn kilőve.
Nem tudom, h bármilyen projectnek helyt adnak-e, vagy sem, de: www.tigris.org?
Sajnos igen.
.NET alatt fejlesztünk, ahhoz meg nagy segítség a Studio.
Megoldani meg egy kicsit nehézkes, hogy a sok sz*r file-t, amit a Studio módosítani akar, egyenként kicsekkoljam. Egy integrált SCC plugin ezt elvégzi automatikusan. A CVS-el nincs is baj ilyen szempontból, de az összefésülésnél gyakran hibázik. A másik probléma meg az "atomic checkins" hiánya.
Sajnos igen.
.NET alatt fejlesztünk, ahhoz meg nagy segítség a Studio.
Megoldani meg egy kicsit nehézkes, hogy a sok sz*r file-t, amit a Studio módosítani akar, egyenként kicsekkoljam. Egy integrált SCC plugin ezt elvégzi automatikusan. A CVS-el nincs is baj ilyen szempontból, de az összefésülésnél gyakran hibázik. A másik probléma meg az "atomic checkins" hiánya.
A subversion eseteben nincs checkout, tehat ez nem gond, na meg a checkin is atomic. Branch mergelesssel meg nincs tapasztalatom. (Na ez mind szep magyarul van. :-))
[quote:0a8ec5de15="fdavid"]A subversion eseteben nincs checkout, tehat ez nem gond, na meg a checkin is atomic. Branch mergelesssel meg nincs tapasztalatom. (Na ez mind szep magyarul van. :-))
Nincs checkout?
Akkor hogyan kérsz kizárólagos jogot egy file módosítására?
[quote:dd3a71ac71="sz"][quote:dd3a71ac71="fdavid"]FSFS, ha nem akarsz adatvesztest.
Lasd meg:
http://hup.hu/modules.php?name=Forums&file=viewtopic&t=3199&highlight=
(Ha elolvasod a topicot, akkor meg annyit, hogy termeszetesen nem sikerult a BerkeleyDB-ket megmenteni.)
[quote:22a8d277d1="Dolphy"][quote:22a8d277d1="fdavid"]A subversion eseteben nincs checkout, tehat ez nem gond, na meg a checkin is atomic. Branch mergelesssel meg nincs tapasztalatom. (Na ez mind szep magyarul van. :-))
Nincs checkout?
Akkor hogyan kérsz kizárólagos jogot egy file módosítására?
De az minek? CVS, SVN is ha minden igaz, összefésül, ha többen módosítják a fájlt.
[quote:71bcc54bc9="Dolphy"][quote:71bcc54bc9="Panther"]De az minek? CVS, SVN is ha minden igaz, összefésül, ha többen módosítják a fájlt.
Biztos ami ziher alapon.
Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
Nincs igazabol szukseg ra. Ha egy fejleszto elkezd dolgozni egy allapoton es a munkaja elvegzese utan be akarja checkelni a modositasait, akkor ugyis teljes osszehasonlitast kell vegeznie a repository legfrissebb allapotaval. Ha szukseges mergelnie kell, es ez teljesen normalis. Nem mindegy, hogy a checkin vagy a kodolas soran mergel?
A reserved checkout csak hamis biztonsag, de valojaban csak a munkat hatraltatja. Az hogy ket fejleszto nem checkoutolhatja ugyanazta filet egyidejuleg az nem oldja meg az egyideju modositasok problemajat.
Ha egyebkent a mergeles soran az egyik fejleszto felulirana a masik munkajat, akkor ott kommunikacios vagy tervezesi hiba van, ami a szekvencialis modositasokkal (ertsd: reserved checkout) sem kerulheto el.
[quote:6006569299="sz"]Alapvetően nekem is jó volt a CVS, amíg azt használtam, de ugye file átnevezésekor a history "kettétörik", és a per file reviziók is okoztak olykor bosszúságot, ha később több file-t is módosító commitot akartam egyben viszontlátni... De ezekkel a korlátozásokkal egész jól együtt
Nálam csak egy branch volt, saját cvs szerver esetén: cvs szerver leállít, mv-vel fájl átnevez, history file-ban search&replace. Éljen a gányolás.
[quote:1c0f09e06e="mako"]Mi most álltunk át cvs-ről svn-re (két windows és egy linux klienssel), és nagyon meg vagyunk vele elégedve. Legnagyobb negatívumként én is a támogatottságot hoznám, grafikus kliensek száma elég gyér, viszont a SmartSVN elég jól használható (mindkét platformon, bár azt nem igazán értem, hogy az én Sarge-omon mér nem tudok commit üzenetet írni...)
Windows alá a TortoiseSVN-t tudom nagyon javasolni, szerintem nagyon kényelmes. Plusz az Eclipse-hez van SVN plugin, amit szintén megelégedettséggel használok. Plusz Linuxra ott a parancssor, az se rossz, bár komplexebb műveletekre azért értelemszerűen nem használható.
[quote:9953af9196="Boogie"]Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
"Kedvenc"
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
Köszi, ismerem ezt a stuffot.
Ha valaki esetleg aktívan használja, akkor arra lettem volna kiváncsi, hogy hogyan válik be éles környezetben. Napi fejlesztés, branchelés, tagelés, összefésülés, stb.
Egyszóval érdemes-e a CVS-t erre leváltani?
Bocs, hogy idepofátlankodok, de nem tudnátok adni valami jó angol || magyar leírást úgy általában a verziókövető rendszerek használatához? Tehát mikor szokás commitolni meg ilyenek. Valami esettanulmány kéne, ami leírja, hogy a gyakorlatban hogyan is működik ez.
Én a munkahelyen megpróbáltam bevezetni, de csak és kizárólag azért, mert többen fejlesztünk 1 kódot, és egyszerűbb egy központi helyről lekérni mindig a legfrissebb változatot, mint másolgatni ide-oda a hálózaton.
[quote:c62612d201="sz"][quote:c62612d201="fdavid"]Nem a backupon mult.
Mi nem múlt rajta?
Visszahoztam mentesbol az adatbazisok eltarolt verzioit, azokkal sem volt jobb a helyzet. Probaltam regebbi svn verziokkal is, azokkal sem tudtam a BerkleyDB-ket meggyogyitani.
(Ez egyebkent egy otthoni kis kornyezet, es ket modon is mentek, de 1-2 honapnal regebbi mentesem nem nagyon van.)
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
Nem. Subversionnek van pár olyan feature-je, ami egyedül történő használat során is nagyon jól jön, de a CVS alapból nem tudja, max nagy hekkelések árán (ha egyáltalán).
Bocs, hogy idepofátlankodok, de nem tudnátok adni valami jó angol || magyar leírást úgy általában a verziókövető rendszerek használatához? Tehát mikor szokás commitolni meg ilyenek. Valami esettanulmány kéne, ami leírja, hogy a gyakorlatban hogyan is működik ez.
Én a munkahelyen megpróbáltam bevezetni, de csak és kizárólag azért, mert többen fejlesztünk 1 kódot, és egyszerűbb egy központi helyről lekérni mindig a legfrissebb változatot, mint másolgatni ide-oda a hálózaton.
Kösz a segítséget :)
Itt nincs altalanos megoldas. A modszereknek, az eszkozoknek, es feladat- es felelossegkiosztasoknak egy fejlesztesi folyamatleirashoz (Develpment Process) kell igazodnia. Ez utobbi pedig vallalatonkent es alkalmazott minosegbizotsitasi szbavanyonkent eltero lehet.
Ilyen folyamaleiras hianyaban nem nagyon lehet jobbat tenni, mint a fejlesztok tapasztalatara hagyatkozni. Altalaban kis cegeknel tapasztalatokon alapulo hazi szabalyrendszereket szoktak hasznalni. Ezek tobbsegukben meglehetosen rosszak es hianyosak, de jobb, mint a semmi.
A www.tigris.org -on nezz korul, emlekeim szerint van egy szabadon elerheto altalanos folyamatleirasuk. Persze, hogy mikor commitolj, az abbol meg kozvetlenul nem fog kovetkezni.
Köszi, ismerem ezt a stuffot.
Ha valaki esetleg aktívan használja, akkor arra lettem volna kiváncsi, hogy hogyan válik be éles környezetben. Napi fejlesztés, branchelés, tagelés, összefésülés, stb.
Egyszóval érdemes-e a CVS-t erre leváltani?
az svn-nek az általad említett utasításai mind konstans egységnyi műveletek! egyébként konkrétan ilyen hogy branch, tag nincs is benne, csak egy konvenció van, hogy a projected (repository) gyökerében elhelyezel 3 könyvtárat: branches/, tags/, trunk/ és ezek alá dolgozol értelemszerűen.
de érdemes elolvasni a leírását, nagyon jó kis pdf! abban minden pontosan levan írva. ja ha már esetleg odáig eljutnátok, hogy átállnátok, akkor ajánlott az 1.2-es szériára átállni!
Nagyon jó ez a SubVersion!
Mondjuk egy komolyabb branch merge-lés még nem volt, de nagyon tetszik ez a Tortoise + Ankh páros. Linuxos szerverrel persze. :)
FSFS + napi backup remélem elég lesz az adatvesztések elkerülésére.
A szerver svnserve, mivel Apache frissítéshez és konfiguráláshoz nem volt túl sok kedvem, egy kérdésem lenne ezzel kapcsolatban:
Be lehet valahol állítani a szerveren, hogy log message nélkül ne fogadjon el commitot?
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
Nem. Subversionnek van pár olyan feature-je, ami egyedül történő használat során is nagyon jól jön, de a CVS alapból nem tudja, max nagy hekkelések árán (ha egyáltalán).
Mit nem??? Nem használok CVS-t, nem egyedül fejlesztek, gondom van vele, ismerek mást, nem logikus, vagy nem a CVS-re szavaztam, esetleg az SVN rossszabb?
Bocs, hogy idepofátlankodok, de nem tudnátok adni valami jó angol || magyar leírást úgy általában a verziókövető rendszerek használatához? Tehát mikor szokás commitolni meg ilyenek. Valami esettanulmány kéne, ami leírja, hogy a gyakorlatban hogyan is működik ez.
Én a munkahelyen megpróbáltam bevezetni, de csak és kizárólag azért, mert többen fejlesztünk 1 kódot, és egyszerűbb egy központi helyről lekérni mindig a legfrissebb változatot, mint másolgatni ide-oda a hálózaton.
Kösz a segítséget :)
huvazz, kb 1.5 éve énis valahogy így szenvedtem ... :))) míg úgy nem döntöttem, hogy kipróbálnám először a mindenki által preferált cvs-t, de aztán kisebb-nagyobb szívások közepette elolvastam még az svn-n leírását is! hát az hogyismondjam, maga volt a megváltás mire már végre svn-ben volt az egész project!
teljesen a nulláról indítja a felhasználót, olyan szintről, hogy aki még életében max. csak futólag hallott arról, hogy mi az az SCM (source control management) azis lazán megértse! egyszerűen nagyon jó a leírása. kezdőtől a haladóig. és nem csak konkrétan magáról az svn-ről van benne szó, hanem az elvekről is. ide tartozik az is, hogy hogyan érdemes használni az egészet, mikor célszerű commitolni. hogyan kell elviekben az ütközéseket feloldani(persze utána egyből rátér a gyakorlatra is!). szóval nagyon jó általános betekintést is nyújt magába az általad feltett kérdésbe is! nagyon jó a szerver felállításának a leírása is, nagyon jól lehet kezelni benne a jogokat. van az esetlegesen cvs-ről áttérőknek összehasonlítás is!
nagyon érdemes elolvasni és utána felinstallálni/használni, mert a rá szánt egy-két hét iszonyatosan gyorsan megtérül!!!
[quote:4d38a4b1ff="Panther"]Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
[quote:e537eb80cb="fdavid"]Visszahoztam mentesbol az adatbazisok eltarolt verzioit, azokkal sem volt jobb a helyzet. Probaltam regebbi svn verziokkal is, azokkal sem tudtam a BerkleyDB-ket meggyogyitani.
(Ez egyebkent egy otthoni kis kornyezet, es ket modon is mentek, de 1-2 honapnal regebbi mentesem nem nagyon van.)
Mit értesz adatbázisok eltárolt verziói alatt? Jól sejtem, h nem dumpot?
[quote:20299632fe="Panther"][quote:20299632fe="Boogie"]Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
"Kedvenc"
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
énis a vindózt imádtam mígnem 7 évvel ezelőtt ki nem próbáltam egy linux disztribet ...
a többit nem részletezem ...
[quote:8007c20b3f="Dolphy"]Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
Erre szokás mondani, h semelyik verziókezelő rendszer nem helyettesíti a fejlesztők közötti kommunikációt.
Viszont a Subversion 1.2 már támogat reserved checkout-ot is. De nem az általad említett esetek miatt, hanem mert a való világban időnként bináris adatot is kell verziókezelni, ahol a soralapon jól működő 'copy-modify-merge' modell nem/nehezen alkalmazható.
[quote:23749369bb="sz"][quote:23749369bb="Dolphy"]Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
Erre szokás mondani, h semelyik verziókezelő rendszer nem helyettesíti a fejlesztők közötti kommunikációt.
Viszont a Subversion 1.2 már támogat reserved checkout-ot is. De nem az általad említett esetek miatt, hanem mert a való világban időnként bináris adatot is kell verziókezelni, ahol a soralapon jól működő 'copy-modify-merge' modell nem/nehezen alkalmazható.
ja, és pont az a jó az svn-ben, hogy mindenféle hókusz-pókusz nélkül alapból kezeli a bináris fájlokat, nemúgy mint a cvs ...
ráadásul vmi olyan változást csináltak az 1.2-ben amivel ezek a bináris fájlok baromi gyorsan be lehet kommitelni! tapasztalatból mondom, mert először még 1.0 val kezdtem, majd jött az 1.1, majd utána jött az 1.2. de írták benne, hogy binárisan inkompatibilisek, de csak annyira, hogy ha valaki még a régivel hozta létre a repot akkor ugyanúgy lassan kezeli. na én erre svndump-pal kidumpoltam, repot devnullba, majd 1.2-vel újrakreáltam és betöltöttem a dumpot. azóta olyan állat gyorsan megy a bináris cuccok ki/be hogy öröm nézni!
[quote:e3feaa95a6="Panther"][quote:e3feaa95a6="suti"]énis a vindózt imádtam mígnem 7 évvel ezelőtt ki nem próbáltam egy linux disztribet ...
a többit nem részletezem ...
Mit akarsz ezzel mondani? :)
hát, hogy az ember addig használ cvs-t míg ki nem próbálja az svn-t ...
Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
btw, elolvastad a hozzászólásom lényegi részét is?
Igen, elolvastam. Csak épp ha nekem jó az, ami van, akkor miért váltanák? Ráadásul Sourceforge.net-en csak CVS van, innentől azt hiszem, trivi, hogy svn kilőve.
[quote:6615b54efa="sz"][quote:6615b54efa="fdavid"]Visszahoztam mentesbol az adatbazisok eltarolt verzioit, azokkal sem volt jobb a helyzet. Probaltam regebbi svn verziokkal is, azokkal sem tudtam a BerkleyDB-ket meggyogyitani.
(Ez egyebkent egy otthoni kis kornyezet, es ket modon is mentek, de 1-2 honapnal regebbi mentesem nem nagyon van.)
Mit értesz adatbázisok eltárolt verziói alatt? Jól sejtem, h nem dumpot?
Igen, jol sejted. En nem vagyok admin, csak felhasznalo. Otthon kenyszerbol adminolok, es tanulok a hibaimbol. Pl. oromteli volt, hogy csak tesztrendszerkent futtattam egy ideig a BerkleyDB-ket, es igy nem veszett el fontos adat.
Most ugy veszem ki a szavaidbol, hogy a dumpot (is?) kellet volna mentenem, amit hat nem tettem, mert csak siman a filejaimrol csinalok mentest.
Hogy haszna is legyen a dolognak, megkerdezem, hogy akkor az fsfs tarolasi rendszerhez van-e vmi mentesi eljaras, amit alkalmaznom kellene?
[quote:e890e8897b="fdavid"]Most ugy veszem ki a szavaidbol, hogy a dumpot (is?) kellet volna mentenem, amit hat nem tettem, mert csak siman a filejaimrol csinalok mentest.
Hogy haszna is legyen a dolognak, megkerdezem, hogy akkor az fsfs tarolasi rendszerhez van-e vmi mentesi eljaras, amit alkalmaznom kellene?
Subversionnél vannak ún. hookok, amik tulajdonképpen külső programok vagy scriptek, melyek bizonyos eseményekkor (commit előtt, commit után, stb) végrehajtásra kerülnek. Közülük a post-commit hook az érdekes, ami minden commit után lefut, és megkapja paraméterként az éppen commitolt revision azonosítóját. No, ennek segítségével minden commit után automatikusan készítek egy inkrementális dumpot (nagy vonalakban: svnadmin -q dump ${REPO} -r ${REV} --incremental |gzip -9 >${dumpfile_base}_${REV}.gz), amit a vinyó megdöglésétől való félelmemben scpvel egyből át is másolok egy másik gépre.
Ami ebben jó, h ami egyszer ki lett dumpolva, az ki van dumpolva (; Az már nem fog változni újabb revisionök commitolásával, így a data-store (legyen akár BerkeleyDB, akár FSFS) nyugodtan összerogyhat alatta upgrade miatt, vagy akár a saját, akár filerendszer, akár vinyó hibájából. (Persze ha egy vinyón vannak a dumpok és a repo, és a vinyó megdeglik, akkor "az ellen nem véd".)
[quote:5adaae1faa="Boogie"]Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
Mi most álltunk át cvs-ről svn-re (két windows és egy linux klienssel), és nagyon meg vagyunk vele elégedve. Legnagyobb negatívumként én is a támogatottságot hoznám, grafikus kliensek száma elég gyér, viszont a SmartSVN elég jól használható (mindkét platformon, bár azt nem igazán értem, hogy az én Sarge-omon mér nem tudok commit üzenetet írni...)
[quote:bee432d130="sz"][quote:bee432d130="fdavid"]Most ugy veszem ki a szavaidbol, hogy a dumpot (is?) kellet volna mentenem, amit hat nem tettem, mert csak siman a filejaimrol csinalok mentest.
Hogy haszna is legyen a dolognak, megkerdezem, hogy akkor az fsfs tarolasi rendszerhez van-e vmi mentesi eljaras, amit alkalmaznom kellene?
Subversionnél vannak ún. hookok, amik tulajdonképpen külső programok vagy scriptek, melyek bizonyos eseményekkor (commit előtt, commit után, stb) végrehajtásra kerülnek. Közülük a post-commit hook az érdekes, ami minden commit után lefut, és megkapja paraméterként az éppen commitolt revision azonosítóját. No, ennek segítségével minden commit után automatikusan készítek egy inkrementális dumpot (nagy vonalakban: svnadmin -q dump ${REPO} -r ${REV} --incremental |gzip -9 >${dumpfile_base}_${REV}.gz), amit a vinyó megdöglésétől való félelmemben scpvel egyből át is másolok egy másik gépre.
Ami ebben jó, h ami egyszer ki lett dumpolva, az ki van dumpolva (; Az már nem fog változni újabb revisionök commitolásával, így a data-store (legyen akár BerkeleyDB, akár FSFS) nyugodtan összerogyhat alatta upgrade miatt, vagy akár a saját, akár filerendszer, akár vinyó hibájából. (Persze ha egy vinyón vannak a dumpok és a repo, és a vinyó megdeglik, akkor "az ellen nem véd".)
Hozzászólások
[quote:4770eef4b5="Panther"]Igen, elolvastam. Csak épp ha nekem jó az, ami van, akkor miért váltanák?
Ezért:[quote:4770eef4b5="suti"]az ember addig használ cvs-t míg ki nem próbálja az svn-t ...
Alapvetően nekem is jó volt a CVS, amíg azt használtam, de ugye file átnevezésekor a history "kettétörik", és a per file reviziók is okoztak olykor bosszúságot, ha később több file-t is módosító commitot akartam egyben viszontlátni... De ezekkel a korlátozásokkal egész jól együtt lehetett élni.
Aztán jött egyik kolléga, h vessek én is egy pillantást a Subversionre... Nem tartott túl sokáig, amíg az egész tanszék (az RCS írója vezeti...) átállt CVS-ről Subversionre, és csodálkoznak, h hogyan tudtak egyáltalán annyi ideig meglenni a CVS-sel.
[quote:4770eef4b5="Panther"]Ráadásul Sourceforge.net-en csak CVS van, innentől azt hiszem, trivi, hogy svn kilőve.
Nem tudom, h bármilyen projectnek helyt adnak-e, vagy sem, de: www.tigris.org?
BerkeleyDB vagy FSFS?
[quote:8064cec63d="fdavid"]FSFS, ha nem akarsz adatvesztest.
Lasd meg:
http://hup.hu/modules.php?name=Forums&file=viewtopic&t=3199&highlight=
(Ha elolvasod a topicot, akkor meg annyit, hogy termeszetesen nem sikerult a BerkeleyDB-ket megmenteni.)
A backup az mindenképpen fontos dolog (;
A 2005-ös év kedvenc szabad verziókövető/CM rendszere.
[quote:35a3422ca1="Dolphy"]- használja valaki windows-on visual studio-ba integrálva?
Csak integráltan jó? Eclipse+SubEclipse-t és/vagy TortoiseSVN-t ajánlom figyelmedbe.
[quote:26870ee251="Dolphy"]BerkeleyDB vagy FSFS?
FSFS, ha nem akarsz adatvesztest.
Lasd meg:
http://hup.hu/modules.php?name=Forums&file=viewtopic&t=3199&highlight=
(Ha elolvasod a topicot, akkor meg annyit, hogy termeszetesen nem sikerult a BerkeleyDB-ket megmenteni.)
[quote:bc72427bc5="Boogie"]Csak integráltan jó? Eclipse+SubEclipse-t és/vagy TortoiseSVN-t ajánlom figyelmedbe.
Sajnos igen.
.NET alatt fejlesztünk, ahhoz meg nagy segítség a Studio.
Megoldani meg egy kicsit nehézkes, hogy a sok sz*r file-t, amit a Studio módosítani akar, egyenként kicsekkoljam. Egy integrált SCC plugin ezt elvégzi automatikusan. A CVS-el nincs is baj ilyen szempontból, de az összefésülésnél gyakran hibázik. A másik probléma meg az "atomic checkins" hiánya.
[quote:437aadee03="Dolphy"][quote:437aadee03="Boogie"]Csak integráltan jó? Eclipse+SubEclipse-t és/vagy TortoiseSVN-t ajánlom figyelmedbe.
Sajnos igen.
.NET alatt fejlesztünk, ahhoz meg nagy segítség a Studio.
Megoldani meg egy kicsit nehézkes, hogy a sok sz*r file-t, amit a Studio módosítani akar, egyenként kicsekkoljam. Egy integrált SCC plugin ezt elvégzi automatikusan. A CVS-el nincs is baj ilyen szempontból, de az összefésülésnél gyakran hibázik. A másik probléma meg az "atomic checkins" hiánya.
A subversion eseteben nincs checkout, tehat ez nem gond, na meg a checkin is atomic. Branch mergelesssel meg nincs tapasztalatom. (Na ez mind szep magyarul van. :-))
[quote:0a8ec5de15="fdavid"]A subversion eseteben nincs checkout, tehat ez nem gond, na meg a checkin is atomic. Branch mergelesssel meg nincs tapasztalatom. (Na ez mind szep magyarul van. :-))
Nincs checkout?
Akkor hogyan kérsz kizárólagos jogot egy file módosítására?
[quote:dd3a71ac71="sz"][quote:dd3a71ac71="fdavid"]FSFS, ha nem akarsz adatvesztest.
Lasd meg:
http://hup.hu/modules.php?name=Forums&file=viewtopic&t=3199&highlight=
(Ha elolvasod a topicot, akkor meg annyit, hogy termeszetesen nem sikerult a BerkeleyDB-ket megmenteni.)
A backup az mindenképpen fontos dolog (;
Nem a backupon mult.
[quote:22a8d277d1="Dolphy"][quote:22a8d277d1="fdavid"]A subversion eseteben nincs checkout, tehat ez nem gond, na meg a checkin is atomic. Branch mergelesssel meg nincs tapasztalatom. (Na ez mind szep magyarul van. :-))
Nincs checkout?
Akkor hogyan kérsz kizárólagos jogot egy file módosítására?
De az minek? CVS, SVN is ha minden igaz, összefésül, ha többen módosítják a fájlt.
[quote:27aba994ba="Panther"]De az minek? CVS, SVN is ha minden igaz, összefésül, ha többen módosítják a fájlt.
Biztos ami ziher alapon.
Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
[quote:71bcc54bc9="Dolphy"][quote:71bcc54bc9="Panther"]De az minek? CVS, SVN is ha minden igaz, összefésül, ha többen módosítják a fájlt.
Biztos ami ziher alapon.
Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
Nincs igazabol szukseg ra. Ha egy fejleszto elkezd dolgozni egy allapoton es a munkaja elvegzese utan be akarja checkelni a modositasait, akkor ugyis teljes osszehasonlitast kell vegeznie a repository legfrissebb allapotaval. Ha szukseges mergelnie kell, es ez teljesen normalis. Nem mindegy, hogy a checkin vagy a kodolas soran mergel?
A reserved checkout csak hamis biztonsag, de valojaban csak a munkat hatraltatja. Az hogy ket fejleszto nem checkoutolhatja ugyanazta filet egyidejuleg az nem oldja meg az egyideju modositasok problemajat.
Ha egyebkent a mergeles soran az egyik fejleszto felulirana a masik munkajat, akkor ott kommunikacios vagy tervezesi hiba van, ami a szekvencialis modositasokkal (ertsd: reserved checkout) sem kerulheto el.
[quote:6006569299="sz"]Alapvetően nekem is jó volt a CVS, amíg azt használtam, de ugye file átnevezésekor a history "kettétörik", és a per file reviziók is okoztak olykor bosszúságot, ha később több file-t is módosító commitot akartam egyben viszontlátni... De ezekkel a korlátozásokkal egész jól együtt
Nálam csak egy branch volt, saját cvs szerver esetén: cvs szerver leállít, mv-vel fájl átnevez, history file-ban search&replace. Éljen a gányolás.
No ezt az svn-t megtekintem közelebbről :P
[quote:1c0f09e06e="mako"]Mi most álltunk át cvs-ről svn-re (két windows és egy linux klienssel), és nagyon meg vagyunk vele elégedve. Legnagyobb negatívumként én is a támogatottságot hoznám, grafikus kliensek száma elég gyér, viszont a SmartSVN elég jól használható (mindkét platformon, bár azt nem igazán értem, hogy az én Sarge-omon mér nem tudok commit üzenetet írni...)
Windows alá a TortoiseSVN-t tudom nagyon javasolni, szerintem nagyon kényelmes. Plusz az Eclipse-hez van SVN plugin, amit szintén megelégedettséggel használok. Plusz Linuxra ott a parancssor, az se rossz, bár komplexebb műveletekre azért értelemszerűen nem használható.
[quote:9953af9196="Boogie"]Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
"Kedvenc"
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
[quote:69668e6e00="Dolphy"]Lenne pár kérdésem a subversion-nel kapcsolatban:
- használja valaki windows-on visual studio-ba integrálva?
- branch-ek összefésülése hogy megy?
- milyenek a tapasztalatok?
SourceSafe ill. Team System helyett kéne ingyenes alternatíva, jelenleg CVS fut a PushOK-féle SCC pluginnal, de enyhén szólva van bajunk vele.
thx,
Dolphy
http://ankhsvn.tigris.org/
[quote:45b81b47ac="Ochronus"]http://ankhsvn.tigris.org/
Köszi, ismerem ezt a stuffot.
Ha valaki esetleg aktívan használja, akkor arra lettem volna kiváncsi, hogy hogyan válik be éles környezetben. Napi fejlesztés, branchelés, tagelés, összefésülés, stb.
Egyszóval érdemes-e a CVS-t erre leváltani?
[quote:9da82917d4="fdavid"]Nem a backupon mult.
Mi nem múlt rajta?
Üdv!
Bocs, hogy idepofátlankodok, de nem tudnátok adni valami jó angol || magyar leírást úgy általában a verziókövető rendszerek használatához? Tehát mikor szokás commitolni meg ilyenek. Valami esettanulmány kéne, ami leírja, hogy a gyakorlatban hogyan is működik ez.
Én a munkahelyen megpróbáltam bevezetni, de csak és kizárólag azért, mert többen fejlesztünk 1 kódot, és egyszerűbb egy központi helyről lekérni mindig a legfrissebb változatot, mint másolgatni ide-oda a hálózaton.
Kösz a segítséget :)
[quote:c62612d201="sz"][quote:c62612d201="fdavid"]Nem a backupon mult.
Mi nem múlt rajta?
Visszahoztam mentesbol az adatbazisok eltarolt verzioit, azokkal sem volt jobb a helyzet. Probaltam regebbi svn verziokkal is, azokkal sem tudtam a BerkleyDB-ket meggyogyitani.
(Ez egyebkent egy otthoni kis kornyezet, es ket modon is mentek, de 1-2 honapnal regebbi mentesem nem nagyon van.)
[quote:54bf1ac0d3="Panther"]"Kedvenc"
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
Nem. Subversionnek van pár olyan feature-je, ami egyedül történő használat során is nagyon jól jön, de a CVS alapból nem tudja, max nagy hekkelések árán (ha egyáltalán).
[quote:f0c1a4ad65="laja"]Üdv!
Bocs, hogy idepofátlankodok, de nem tudnátok adni valami jó angol || magyar leírást úgy általában a verziókövető rendszerek használatához? Tehát mikor szokás commitolni meg ilyenek. Valami esettanulmány kéne, ami leírja, hogy a gyakorlatban hogyan is működik ez.
Én a munkahelyen megpróbáltam bevezetni, de csak és kizárólag azért, mert többen fejlesztünk 1 kódot, és egyszerűbb egy központi helyről lekérni mindig a legfrissebb változatot, mint másolgatni ide-oda a hálózaton.
Kösz a segítséget :)
Itt nincs altalanos megoldas. A modszereknek, az eszkozoknek, es feladat- es felelossegkiosztasoknak egy fejlesztesi folyamatleirashoz (Develpment Process) kell igazodnia. Ez utobbi pedig vallalatonkent es alkalmazott minosegbizotsitasi szbavanyonkent eltero lehet.
Ilyen folyamaleiras hianyaban nem nagyon lehet jobbat tenni, mint a fejlesztok tapasztalatara hagyatkozni. Altalaban kis cegeknel tapasztalatokon alapulo hazi szabalyrendszereket szoktak hasznalni. Ezek tobbsegukben meglehetosen rosszak es hianyosak, de jobb, mint a semmi.
A www.tigris.org -on nezz korul, emlekeim szerint van egy szabadon elerheto altalanos folyamatleirasuk. Persze, hogy mikor commitolj, az abbol meg kozvetlenul nem fog kovetkezni.
[quote:5656712b02="Dolphy"][quote:5656712b02="Ochronus"]http://ankhsvn.tigris.org/
Köszi, ismerem ezt a stuffot.
Ha valaki esetleg aktívan használja, akkor arra lettem volna kiváncsi, hogy hogyan válik be éles környezetben. Napi fejlesztés, branchelés, tagelés, összefésülés, stb.
Egyszóval érdemes-e a CVS-t erre leváltani?
az svn-nek az általad említett utasításai mind konstans egységnyi műveletek! egyébként konkrétan ilyen hogy branch, tag nincs is benne, csak egy konvenció van, hogy a projected (repository) gyökerében elhelyezel 3 könyvtárat: branches/, tags/, trunk/ és ezek alá dolgozol értelemszerűen.
de érdemes elolvasni a leírását, nagyon jó kis pdf! abban minden pontosan levan írva. ja ha már esetleg odáig eljutnátok, hogy átállnátok, akkor ajánlott az 1.2-es szériára átállni!
Nagyon jó ez a SubVersion!
Mondjuk egy komolyabb branch merge-lés még nem volt, de nagyon tetszik ez a Tortoise + Ankh páros. Linuxos szerverrel persze. :)
FSFS + napi backup remélem elég lesz az adatvesztések elkerülésére.
A szerver svnserve, mivel Apache frissítéshez és konfiguráláshoz nem volt túl sok kedvem, egy kérdésem lenne ezzel kapcsolatban:
Be lehet valahol állítani a szerveren, hogy log message nélkül ne fogadjon el commitot?
[quote:2d7cc2e9f7="sz"][quote:2d7cc2e9f7="Panther"]"Kedvenc"
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
Nem. Subversionnek van pár olyan feature-je, ami egyedül történő használat során is nagyon jól jön, de a CVS alapból nem tudja, max nagy hekkelések árán (ha egyáltalán).
Mit nem??? Nem használok CVS-t, nem egyedül fejlesztek, gondom van vele, ismerek mást, nem logikus, vagy nem a CVS-re szavaztam, esetleg az SVN rossszabb?
[quote:a4fce20667="laja"]Üdv!
Bocs, hogy idepofátlankodok, de nem tudnátok adni valami jó angol || magyar leírást úgy általában a verziókövető rendszerek használatához? Tehát mikor szokás commitolni meg ilyenek. Valami esettanulmány kéne, ami leírja, hogy a gyakorlatban hogyan is működik ez.
Én a munkahelyen megpróbáltam bevezetni, de csak és kizárólag azért, mert többen fejlesztünk 1 kódot, és egyszerűbb egy központi helyről lekérni mindig a legfrissebb változatot, mint másolgatni ide-oda a hálózaton.
Kösz a segítséget :)
huvazz, kb 1.5 éve énis valahogy így szenvedtem ... :))) míg úgy nem döntöttem, hogy kipróbálnám először a mindenki által preferált cvs-t, de aztán kisebb-nagyobb szívások közepette elolvastam még az svn-n leírását is! hát az hogyismondjam, maga volt a megváltás mire már végre svn-ben volt az egész project!
teljesen a nulláról indítja a felhasználót, olyan szintről, hogy aki még életében max. csak futólag hallott arról, hogy mi az az SCM (source control management) azis lazán megértse! egyszerűen nagyon jó a leírása. kezdőtől a haladóig. és nem csak konkrétan magáról az svn-ről van benne szó, hanem az elvekről is. ide tartozik az is, hogy hogyan érdemes használni az egészet, mikor célszerű commitolni. hogyan kell elviekben az ütközéseket feloldani(persze utána egyből rátér a gyakorlatra is!). szóval nagyon jó általános betekintést is nyújt magába az általad feltett kérdésbe is! nagyon jó a szerver felállításának a leírása is, nagyon jól lehet kezelni benne a jogokat. van az esetlegesen cvs-ről áttérőknek összehasonlítás is!
nagyon érdemes elolvasni és utána felinstallálni/használni, mert a rá szánt egy-két hét iszonyatosan gyorsan megtérül!!!
nah remélem sikerült felbátorítanom téged
[quote:f0e6f7ecce="suti"]
nah remélem sikerült felbátorítanom téged
Igen, sikerült, köszi :)
[quote:4d38a4b1ff="Panther"]Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
Hát már kampányolni sem lehet? ;)
[quote:e537eb80cb="fdavid"]Visszahoztam mentesbol az adatbazisok eltarolt verzioit, azokkal sem volt jobb a helyzet. Probaltam regebbi svn verziokkal is, azokkal sem tudtam a BerkleyDB-ket meggyogyitani.
(Ez egyebkent egy otthoni kis kornyezet, es ket modon is mentek, de 1-2 honapnal regebbi mentesem nem nagyon van.)
Mit értesz adatbázisok eltárolt verziói alatt? Jól sejtem, h nem dumpot?
[quote:20299632fe="Panther"][quote:20299632fe="Boogie"]Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
"Kedvenc"
Szerintem az svn jobb, no de én cvs-t használok, mert egyedül fejlesztek, így nincsen gondom vele. Tekintve hogy nem igazán ismerek mást, logikus, hogy a cvs-re szavazok. Nemde?
énis a vindózt imádtam mígnem 7 évvel ezelőtt ki nem próbáltam egy linux disztribet ...
a többit nem részletezem ...
[quote:aff415baa9="suti"]énis a vindózt imádtam mígnem 7 évvel ezelőtt ki nem próbáltam egy linux disztribet ...
a többit nem részletezem ...
Mit akarsz ezzel mondani? :)
[quote:8007c20b3f="Dolphy"]Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
Erre szokás mondani, h semelyik verziókezelő rendszer nem helyettesíti a fejlesztők közötti kommunikációt.
Viszont a Subversion 1.2 már támogat reserved checkout-ot is. De nem az általad említett esetek miatt, hanem mert a való világban időnként bináris adatot is kell verziókezelni, ahol a soralapon jól működő 'copy-modify-merge' modell nem/nehezen alkalmazható.
[quote:23749369bb="sz"][quote:23749369bb="Dolphy"]Egy projekten nem dolgoznak sokan egyszerre (2-3 fejlesztő max), és így elkerülünk néhány felesleges conflictot.
Erre szokás mondani, h semelyik verziókezelő rendszer nem helyettesíti a fejlesztők közötti kommunikációt.
Viszont a Subversion 1.2 már támogat reserved checkout-ot is. De nem az általad említett esetek miatt, hanem mert a való világban időnként bináris adatot is kell verziókezelni, ahol a soralapon jól működő 'copy-modify-merge' modell nem/nehezen alkalmazható.
ja, és pont az a jó az svn-ben, hogy mindenféle hókusz-pókusz nélkül alapból kezeli a bináris fájlokat, nemúgy mint a cvs ...
ráadásul vmi olyan változást csináltak az 1.2-ben amivel ezek a bináris fájlok baromi gyorsan be lehet kommitelni! tapasztalatból mondom, mert először még 1.0 val kezdtem, majd jött az 1.1, majd utána jött az 1.2. de írták benne, hogy binárisan inkompatibilisek, de csak annyira, hogy ha valaki még a régivel hozta létre a repot akkor ugyanúgy lassan kezeli. na én erre svndump-pal kidumpoltam, repot devnullba, majd 1.2-vel újrakreáltam és betöltöttem a dumpot. azóta olyan állat gyorsan megy a bináris cuccok ki/be hogy öröm nézni!
[quote:05b1e3e041="Panther"]Mit nem???
Ezt nem:
[quote:05b1e3e041="Panther"]Nemde?
btw, elolvastad a hozzászólásom lényegi részét is?
[quote:e3feaa95a6="Panther"][quote:e3feaa95a6="suti"]énis a vindózt imádtam mígnem 7 évvel ezelőtt ki nem próbáltam egy linux disztribet ...
a többit nem részletezem ...
Mit akarsz ezzel mondani? :)
hát, hogy az ember addig használ cvs-t míg ki nem próbálja az svn-t ...
Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
[quote:1eec1a1548="sz"][quote:1eec1a1548="Panther"]Mit nem???
Ezt nem:
[quote:1eec1a1548="Panther"]Nemde?
btw, elolvastad a hozzászólásom lényegi részét is?
Igen, elolvastam. Csak épp ha nekem jó az, ami van, akkor miért váltanák? Ráadásul Sourceforge.net-en csak CVS van, innentől azt hiszem, trivi, hogy svn kilőve.
[quote:6615b54efa="sz"][quote:6615b54efa="fdavid"]Visszahoztam mentesbol az adatbazisok eltarolt verzioit, azokkal sem volt jobb a helyzet. Probaltam regebbi svn verziokkal is, azokkal sem tudtam a BerkleyDB-ket meggyogyitani.
(Ez egyebkent egy otthoni kis kornyezet, es ket modon is mentek, de 1-2 honapnal regebbi mentesem nem nagyon van.)
Mit értesz adatbázisok eltárolt verziói alatt? Jól sejtem, h nem dumpot?
Igen, jol sejted. En nem vagyok admin, csak felhasznalo. Otthon kenyszerbol adminolok, es tanulok a hibaimbol. Pl. oromteli volt, hogy csak tesztrendszerkent futtattam egy ideig a BerkleyDB-ket, es igy nem veszett el fontos adat.
Most ugy veszem ki a szavaidbol, hogy a dumpot (is?) kellet volna mentenem, amit hat nem tettem, mert csak siman a filejaimrol csinalok mentest.
Hogy haszna is legyen a dolognak, megkerdezem, hogy akkor az fsfs tarolasi rendszerhez van-e vmi mentesi eljaras, amit alkalmaznom kellene?
Lenne pár kérdésem a subversion-nel kapcsolatban:
- használja valaki windows-on visual studio-ba integrálva?
- branch-ek összefésülése hogy megy?
- milyenek a tapasztalatok?
SourceSafe ill. Team System helyett kéne ingyenes alternatíva, jelenleg CVS fut a PushOK-féle SCC pluginnal, de enyhén szólva van bajunk vele.
thx,
Dolphy
[quote:e890e8897b="fdavid"]Most ugy veszem ki a szavaidbol, hogy a dumpot (is?) kellet volna mentenem, amit hat nem tettem, mert csak siman a filejaimrol csinalok mentest.
Hogy haszna is legyen a dolognak, megkerdezem, hogy akkor az fsfs tarolasi rendszerhez van-e vmi mentesi eljaras, amit alkalmaznom kellene?
Subversionnél vannak ún. hookok, amik tulajdonképpen külső programok vagy scriptek, melyek bizonyos eseményekkor (commit előtt, commit után, stb) végrehajtásra kerülnek. Közülük a post-commit hook az érdekes, ami minden commit után lefut, és megkapja paraméterként az éppen commitolt revision azonosítóját. No, ennek segítségével minden commit után automatikusan készítek egy inkrementális dumpot (nagy vonalakban: svnadmin -q dump ${REPO} -r ${REV} --incremental |gzip -9 >${dumpfile_base}_${REV}.gz), amit a vinyó megdöglésétől való félelmemben scpvel egyből át is másolok egy másik gépre.
Ami ebben jó, h ami egyszer ki lett dumpolva, az ki van dumpolva (; Az már nem fog változni újabb revisionök commitolásával, így a data-store (legyen akár BerkeleyDB, akár FSFS) nyugodtan összerogyhat alatta upgrade miatt, vagy akár a saját, akár filerendszer, akár vinyó hibájából. (Persze ha egy vinyón vannak a dumpok és a repo, és a vinyó megdeglik, akkor "az ellen nem véd".)
[quote:5adaae1faa="Boogie"]Aki a CVS-re szavaz, az próbálta már az SVN-t? :) Mert én próbáltam mindkettőt, és bár a CVS-re igaz, hogy talán jobb a támogatottsága (még), viszont hogy ez valakinek a kedvence legyen a jó sok hibájával, azt nehezen tudom elképzelni. De hát ezért vagyunk különözőek. ;)
Mi most álltunk át cvs-ről svn-re (két windows és egy linux klienssel), és nagyon meg vagyunk vele elégedve. Legnagyobb negatívumként én is a támogatottságot hoznám, grafikus kliensek száma elég gyér, viszont a SmartSVN elég jól használható (mindkét platformon, bár azt nem igazán értem, hogy az én Sarge-omon mér nem tudok commit üzenetet írni...)
[quote:bee432d130="sz"][quote:bee432d130="fdavid"]Most ugy veszem ki a szavaidbol, hogy a dumpot (is?) kellet volna mentenem, amit hat nem tettem, mert csak siman a filejaimrol csinalok mentest.
Hogy haszna is legyen a dolognak, megkerdezem, hogy akkor az fsfs tarolasi rendszerhez van-e vmi mentesi eljaras, amit alkalmaznom kellene?
Subversionnél vannak ún. hookok, amik tulajdonképpen külső programok vagy scriptek, melyek bizonyos eseményekkor (commit előtt, commit után, stb) végrehajtásra kerülnek. Közülük a post-commit hook az érdekes, ami minden commit után lefut, és megkapja paraméterként az éppen commitolt revision azonosítóját. No, ennek segítségével minden commit után automatikusan készítek egy inkrementális dumpot (nagy vonalakban: svnadmin -q dump ${REPO} -r ${REV} --incremental |gzip -9 >${dumpfile_base}_${REV}.gz), amit a vinyó megdöglésétől való félelmemben scpvel egyből át is másolok egy másik gépre.
Ami ebben jó, h ami egyszer ki lett dumpolva, az ki van dumpolva (; Az már nem fog változni újabb revisionök commitolásával, így a data-store (legyen akár BerkeleyDB, akár FSFS) nyugodtan összerogyhat alatta upgrade miatt, vagy akár a saját, akár filerendszer, akár vinyó hibájából. (Persze ha egy vinyón vannak a dumpok és a repo, és a vinyó megdeglik, akkor "az ellen nem véd".)
Nagyon koszi, megnzem!