verzió kontroll kezdőnek

mivel csak subversiont hasznalok, nem tudom mas rendszerekkel osszehasonlitani - de az altalad tamasztott kovetelmenyeknek boven megfelel (binarisok kezeleset is beleertve)

bovebb info: http://subversion.tigris.org/ (Subversion's Features)

[quote:464056cf7f="horvatha"]
Ilyesmiket kellene tudnia:
1) az alapfunkciók viszonylag könnyen megtanulhatók legyenek
2) max 5 ember dolgozik egy projekten
3) max 20 szöveges forrásfájl de sok tucat ábra (bináris) kezelése
4) nem kell grafikus előtét, szeretjük a parancssort
5) Linux alá ingyen elérhető legyen

Főleg az ábrák kezelését nem tudom, melyik oldja meg jobban. Annál nem is kellene a régi verziók követhetősége, csak az összehangolás a repository-val.

CVS, SVN vagy Arch is jo lehet, mindegyik megfelel a fenti kovetelmenyeknek.

Nehany pro- es kontra:

CVS:
- pro: egyszeru, jol dokumentalt, elterjedt, es alig kell configolni
- kontra: atnevezeseket nem supportal, offline mukodest szinten nem, branchok mergelese szinten problemas lehet

SVN:
- pro: cvs on steroids, tudja amit a cvs es meg tobbet
- kontra: az adatbazisa szeret korruptalodni tapasztalataim szerint, es a beallitasa sem annyira trivialis

Arch:
- pro: mindent tud amit a fentiek, a beallitasa 0 munkat igenyel (kb 3 parancs beallitani), van hozza jo doksi, sok-sok howto, es segitokesz emberek ircen. tovabba tamogatja az offline munkat, eszmeletlen jol lehet mergelni vele, stb.
- kontra: picit nehezkesebb megtanulni, mint a masik kettot. az alapfunkciokat mondjuk itt is egyszeru, azta a 4-5 parancsot.

En azt mondanam, hogy Arch, mert ugyan van par hatranya a tobbivel szemben, rengeteg elonye mellett azok eltorpulnek szerintem. Nemkeves Arch hasznalat utan megprobaltam SVN-t hasznalni, importalni bele a meglevo projectjeim, es par branchot csinalni, majd mergelni... hat, ugy osszevissza kakilta magat hogy orom volt nezni. Pedig tenyleg megprobaltam jol csinalni, csak egyszeruen SVN-t nem arra talaltak ki, amire nekem kellett volna. Ha meg most kezdesz ilyesmit tanulni, akkor miert ne kezd helybol azzal, ami kesobb is jo lehet, nem csak egy kisebb projectnel? :)

Raadasul ha help kell, secperc alatt lehet szerezni (arch kerdesekkel bizalommal lehet hozzam fordulni pl :)

[quote:e800e7e528="algernon"]SVN:
- kontra: az adatbazisa szeret korruptalodni tapasztalataim szerint, es a beallitasa sem annyira trivialis

Régebben nekünk is gyakran volt gond vele, szétesett a Berkeley DB, ki kellett dumpolni, újra összerakni, de az utóbbi időben (1.0 óta) nem igazán tapasztalunk ilyeneket.

A beállítása... nem tudom, nem én csináltam :), de szerintem nem lehet vészesen nehéz. Új repót létrehozni egy parancs és file:// módon máris elérhető. Az apache-ot beállítani, hogy http-vel elérhető legyen, biztos kell egy VirtualHost meg pár parancs, de tuti nem sok, és ezt összesen elég egyszer megcsinálni, nem kell repónként külön, ha a repók egy adott könyvtárban vannak.

Az Arch-ot egyáltalán nem ismerem. A CVS-t csak annyira, hogy sokszor kell más projektek forrásait CVS-ből kinyerni, nem feltétlenül az aktuális verziót, hanem egy régebbit, vagy egy adott változtatáshoz tartozó patchet. Az SVN-t meg annyira ismerem, hogy az összes UHU csomag forrását SVN-ben tároljuk, vagyis rendszeresen használom.

Szubjektív CVS kontra SVN összehasonlítás következik, avagy miért imádom az SVN-t és miért rühellem a CVS-t.

El lehet kezdeni filózni azon hogy a CVS ősrégi tervezésű, a Subversion meg modern, mai igényeket kielégítő, például access control terén meg ilyesmik, de ezt inkább hagyjuk.

Az svn offline is használható elég jól, ellentétben a cvs-sel, tehát helyileg rendelkezésre áll olyan infó, mint fájl eredeti verziója, korábbi logok stb., tehát egy "svn diff" vagy "svn log" vagy "svn revert" vagy ilyesmi parancshoz nem kell elérned a repót.

De nem ez a legnagyobb difi, hanem szerintem az, hogy míg CVS-ben a fájlok mind egyéni életet élnek, addig az SVN-ben az egész repónak van egy szem revision értéke, ami minden commit során nő eggyel, vagyis az egész fájlgyűjteményt egy rendszernek tekinti amit egységesen kezel. CVS-ben mind a mai napig nem tudom, hogy hogyan lehet egy verziókezelt forrásból egy konkrét változtatást kiszedni. Mindig nagy nehezen összeszenvedem, hogy kitalálom, mikor történt a változás, akár mp-re pontosan, és lekérem az ezen időintervallum során történt változásokat. De valahogy semmi nem köti össze két különböző fájl egyidőben történt változtatását. Vagy csak én vagyok ultrapancser. Subversion-ben ezek együtt élnek, ha én módosítok valamit a forráskódon, ami módosítás több fájlt érint, akkor ezeket együtt commitolom be, egy commit lesz az, ami mondjuk 41-ről 42-re billenti a komplett repó revision-jét, és bármikor simán lekérhetem a 41-es és 42-es közti diff-et. Vagyis nem különálló fájlokban, hanem logikailag egy szem projektben gondolkozik (repónként persze). Ennek elsősorban forráskód esetén van haszna, de azt hiszem, LaTeX doksi kezelése esetén is, például ha az összes fájlban az egyik szót kicseréled valami másikra, mert jobban tetszik az új terminológia, vagy ha lecserélsz egy ábrát és a hozzá tartozó szöveget neki megfelelően, ezek mind olyan változtatások, amik több fájlt érintenek, mégis logikailag szervesen összetartoznak, szerintem az a jó, ha a verziókezelő ezeket együtt kezeli, nem külön.

Továbbá van egy olyan érzésem, ezzel összhangban, hogy ami a CVS-ben iszonyúan fölöslegesen túl van bonyolítva, az az SVN-ben mind átlátható, egyszerű, szép. Gondolok például a tök olvasható és elsőre átlátható és nyilvánvaló "svn log" kontra áttekinthetetlen összevissza "cvs log" formátumokra, a mindenféle 1.2.1.1 meg ilyesmi típusú tag-ekre a CVS-ben, ahol a páros sok szám áll, amik kettesével jelentenek valamit. Biztos meg tudnám érteni, ha szükségem volna, vagy ha kíváncsi lennék rá, de nem vagyok rá kíváncsi, mert úgy látom, hogy túlbonyolították, és a Subversion bebizonyította számomra, hogy lehet ugyanezt sokkal tisztábban, egyszerűbben, és csöppet sem kevésbé hatékonyan is.

Szóval az Arch-ot egyáltalán nem ismerem, úgy tudom, az jobban eltér hozzáállásában ettől a kettőtől, de ha CVS kontra SVN gondolkozol, akkor szerintem ne gondolkozz tovább, irány az SVN.

Ja, még annyit, írod ugyebár, hogy a CVS parancssori alap funkcióit ismered, nos, az SVN alap funkciói gyakorlatilag ugyanezek. ci, co, log, diff, revert... teljesen hasonlóan. A tag-elés már picit másképp megy, mert az svn maga tulajdonképpen nem támogatja igazán ezt a fogalmat (avagy ahogy tetszik: gyakorlatilag minden commit egy tag :-)), komolyra fordítva, azt ajánlják, hogy a repó nyitó könyvtárában csinálj tags, branches és trunk nevű könyvtárat, a trunk-ban dolgozz, és a tag gyakorlagilag egy másolás (svn cp) a tags könyvtár alá. Próbáld ki:
svn co https://svn.uhulinux.hu/UHU/cdtest
és megérted. Nekünk már külön saját pár soros szkriptünk van, ami automatikusan a trunk-ot "tag-eli", vagyis másolja a tags alatt a soron következő (vagy általunk megadott) verziószámra.
Ja, és persze bőven elég a trunk könyvtárat kicsekkolni ahhoz hogy dolgozz, a többit csak szükség esetén.

[quote:0089dfa13f="egmont"][quote:0089dfa13f="algernon"]SVN:
- kontra: az adatbazisa szeret korruptalodni tapasztalataim szerint, es a beallitasa sem annyira trivialis

Régebben nekünk is gyakran volt gond vele, szétesett a Berkeley DB, ki kellett dumpolni, újra összerakni, de az utóbbi időben (1.0 óta) nem igazán tapasztalunk ilyeneket.

Nekem ez 1.0 utan volt.

[quote:0089dfa13f="egmont"]A beállítása... nem tudom, nem én csináltam :), de szerintem nem lehet vészesen nehéz. Új repót létrehozni egy parancs és file:// módon máris elérhető. Az apache-ot beállítani, hogy http-vel elérhető legyen, biztos kell egy VirtualHost meg pár parancs, de tuti nem sok, és ezt összesen elég egyszer megcsinálni, nem kell repónként külön, ha a repók egy adott könyvtárban vannak.

Azert kezdonek szerintem egyszerubb, ha nem kell apacheot allitani. (Ok, lehet hogy csak VCS teren kezdo, akkor nem szoltam)

Mindenesetre apacs allitgatassal szemben arch es cvs setup lenyegesen egyszerubbnek tunik.

[quote:0089dfa13f="egmont"]
Az svn offline is használható elég jól, ellentétben a cvs-sel, tehát helyileg rendelkezésre áll olyan infó, mint fájl eredeti verziója, korábbi logok stb., tehát egy "svn diff" vagy "svn log" vagy "svn revert" vagy ilyesmi parancshoz nem kell elérned a repót.

Archnal hasonlo a helyzet. Sot, ott meg lehet azt is csinalni, hogy offline csinalsz egy repot, es onnan mergelnek majd vissza a fo repoba (igy a history sem vesz el, nem kell patcheket kuldozgetni fel ala, stb)

[quote:0089dfa13f="egmont"]
CVS-ben mind a mai napig nem tudom, hogy hogyan lehet egy verziókezelt forrásból egy konkrét változtatást kiszedni. Mindig nagy nehezen összeszenvedem, hogy kitalálom, mikor történt a változás, akár mp-re pontosan, és lekérem az ezen időintervallum során történt változásokat. De valahogy semmi nem köti össze két különböző fájl egyidőben történt változtatását. Vagy csak én vagyok ultrapancser.

Ezt ket modon szoktak orvosolni: ugyanaz a commit log tartozik az egybetartozo commitokhoz, es az alapjan lehet megkeresni az egyes changeseteket (erre van jopar kesz es felkesz tool), vagy nagyobb lenduletu dolgoknal kulon branch, es tag merge elott, es utan.

Egyik sem szep megoldas.. de gondoltam elmondom, hatha hasznos lesz meg valakinek valamikor (nomeg igy jartatom a pofam, mert az nekem jo).

[quote:0089dfa13f="egmont"]
Szóval az Arch-ot egyáltalán nem ismerem, úgy tudom, az jobban eltér hozzáállásában ettől a kettőtől, de ha CVS kontra SVN gondolkozol, akkor szerintem ne gondolkozz tovább, irány az SVN.

Jah. Ha SVN vagy CVS-szeru dolgot keres valaki, akkor SVN. Ha nyitottab kicsit masfele rendszerre is, akkor szerintem Arch erdemesebb.
Amint arra lesz igeny, hogy kulso contributortol patcheket elfogadni, arch szerintem lenyegesen hatekonyabb. Vagy ha nem akarsz se apacheot futtatni, se ssh+svn -t configolni (ugy hallottam idokozben hogy ez utobbi egyszerubb, mint az apacs configolas).

Meg egy jo erv Arch mellett: arch-al megoldhato egy olyan, hogy minden fejlesztonek van kozos repoja, es van egy fo repository, amibe az egyes valtozasok mergelodnek. Van egy arch-pqm nevu program, ami megcsinalja, hogy kuld neki az ember egy requestet hogy ezt-meg-ezt mergeld be, es o megteszi (ha az illetonek van erre jogosultsaga, meg az automatizalt teszteken - ha van - atmegy a program), es hasonlo okossagok.

5 fejlesztonel ez meg nem lenyeg, nagyobb projectnel mar jol jon :)

[quote:0c701d10f1="algernon"]Ezt ket modon szoktak orvosolni: ugyanaz a commit log tartozik az egybetartozo commitokhoz, es az alapjan lehet megkeresni az egyes changeseteket (erre van jopar kesz es felkesz tool), vagy nagyobb lenduletu dolgoknal kulon branch, es tag merge elott, es utan.

Az első, igen, jó megközelítés, hasonló ahhoz amikor dátum alapján keresem, talán picit egyszerűbb, de tényleg kell hozzá valami helper tool, mert parancssorból mindig összeszenvedni kicsit gáz. De köszi az ötletet, legközelebb inkább keresek (vagy írok) progit erre. A második azért nem játszik az én esetemben, mert mások által kezelt CVS-ben (például Gnome) kell túrkálnom, kiszednem egy javítást, ami tudom hogy az X fájl Y sorába beírta hogy Z, de nem tudom, hogy mi mást változtatott még vele egy kalap alatt a forrásban... szóval nekem kell igazodnom az adottságokhoz...

[quote:0c701d10f1="algernon"](nomeg igy jartatom a pofam, mert az nekem jo).

:-D

Mar miert ne lehetne offline hasznalni??

[code:1:eea6d09df9]
$ cvs -d /tmp/foo init
$ mkdir -p /tmp/bar && cd /tmp/bar
$ touch a b c d
$ cvs -d /tmp/foo import bar robert robert_20041016
$ cvs -d /tmp/foo co bar
[/code:1:eea6d09df9]

Ez nem offline!?

[quote:651d909f78="thuglife"]Mar miert ne lehetne offline hasznalni??

[code:1:651d909f78]
$ cvs -d /tmp/foo init
$ mkdir -p /tmp/bar && cd /tmp/bar
$ touch a b c d
$ cvs -d /tmp/foo import bar robert robert_20041016
$ cvs -d /tmp/foo co bar
[/code:1:651d909f78]

Ez nem offline!?

Es ezt vissza tudod mergelni az eredeti repoba ugy, hogy ne vesszen el history?

Meg tudsz olyat, hogy cvs diff vagy cvs log, a checkoutolt konyvtarbol, offline?

[quote:ef07994132="thuglife"]Mar miert ne lehetne offline hasznalni??

Korrekcio: hibasan fogalmaztam, legalabbis nem teljesen vilagosan. Offline alatt itt az a szituacio ertendo, hogy a repo nem az en gepemen van, es nincs net eleresem.

[quote:3cefbaf609="algernon"][quote:3cefbaf609="thuglife"]Mar miert ne lehetne offline hasznalni??

[code:1:3cefbaf609]
$ cvs -d /tmp/foo init
$ mkdir -p /tmp/bar && cd /tmp/bar
$ touch a b c d
$ cvs -d /tmp/foo import bar robert robert_20041016
$ cvs -d /tmp/foo co bar
[/code:1:3cefbaf609]

Ez nem offline!?

Es ezt vissza tudod mergelni az eredeti repoba ugy, hogy ne vesszen el history?

Meg tudsz olyat, hogy cvs diff vagy cvs log, a checkoutolt konyvtarbol, offline?

robert@atlantis:/tmp/bar$ cvs -d /tmp/foo diff -uNR
cvs diff: Diffing .
Index: a
===================================================================
RCS file: /tmp/foo/bar/a,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 a
--- a 15 Oct 2004 22:46:52 -0000 1.1.1.1
+++ a 15 Oct 2004 22:47:06 -0000
@@ -0,0 +1 @@
+bepojfe

---------------------------------------------------------------
Checking in a;
/tmp/foo/bar/a,v <-- a
new revision: 1.2; previous revision: 1.1
done

----------------------------------------------------------------

robert@atlantis:/tmp/bar$ cvs -d /tmp/foo log a

RCS file: /tmp/foo/bar/a,v
Working file: a
head: 1.3
branch:
locks: strict
access list:
symbolic names:
foo2004: 1.1.1.1
foo: 1.1.1
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------
revision 1.3
date: 2004/10/15 22:48:36; author: robert; state: Exp; lines: +1 -0
ez egy commit. log kene hogy legyen
----------------------------
revision 1.2
date: 2004/10/15 22:48:03; author: robert; state: Exp; lines: +1 -0
*** empty log message ***
----------------------------
revision 1.1
date: 2004/10/15 22:46:52; author: robert; state: Exp;
branches: 1.1.1;
Initial revision
----------------------------
revision 1.1.1.1
date: 2004/10/15 22:46:52; author: robert; state: Exp; lines: +0 -0

=============================================================================

[quote:3e9f5a5327="algernon"][quote:3e9f5a5327="thuglife"]Mar miert ne lehetne offline hasznalni??

Korrekcio: hibasan fogalmaztam, legalabbis nem teljesen vilagosan. Offline alatt itt az a szituacio ertendo, hogy a repo nem az en gepemen van, es nincs net eleresem.

Aham. De ilyen modon se SVN -t se arch ot nem tudod hasznalni. Vagy igen?

(Lasd korrekciom: csinald ezt meg ugy, hogy a repo remote gepen van, megis megy offline a diff es a log; Extra bonusz ha offline, commit jog nelkul tudsz taget csinalni [Arch-al ez is megy, local repo felallitasa utan :])

[quote:da84343db1="thuglife"][quote:da84343db1="algernon"][quote:da84343db1="thuglife"]Mar miert ne lehetne offline hasznalni??

Korrekcio: hibasan fogalmaztam, legalabbis nem teljesen vilagosan. Offline alatt itt az a szituacio ertendo, hogy a repo nem az en gepemen van, es nincs net eleresem.

Aham. De ilyen modon se SVN -t se arch ot nem tudod hasznalni. Vagy igen?

Mindkettot tudom. Archot biztosan, SVN-rol azt mondtak, hogy az is tudja.

[quote:4cbab35713="algernon"](Lasd korrekciom: csinald ezt meg ugy, hogy a repo remote gepen van, megis megy offline a diff es a log; Extra bonusz ha offline, commit jog nelkul tudsz taget csinalni [Arch-al ez is megy, local repo felallitasa utan :])

Most neztem meg. Egy public CVS repon. local checkoutoltam foo -t. persze directoryt adtam meg ezutan problema nelkul megy diff es log is.

[quote:1344a6997e="thuglife"]Most neztem meg. Egy public CVS repon. local checkoutoltam foo -t. persze directoryt adtam meg ezutan problema nelkul megy diff es log is.

Ügyi vagy. Segís légyszi, hogy nekem is menjen.
egmont:~/joe-current$ cvs diff
Unknown host cvs.sourceforge.net.
egmont:~/joe-current$

[quote:dfb82f0458="thuglife"][quote:dfb82f0458="algernon"](Lasd korrekciom: csinald ezt meg ugy, hogy a repo remote gepen van, megis megy offline a diff es a log; Extra bonusz ha offline, commit jog nelkul tudsz taget csinalni [Arch-al ez is megy, local repo felallitasa utan :])

Most neztem meg. Egy public CVS repon. local checkoutoltam foo -t. persze directoryt adtam meg ezutan problema nelkul megy diff es log is.

[code:1:dfb82f0458]
34837:algernon@melkor: /tmp/ffmpeg] cat CVS/Root
:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg
34838:algernon@melkor: /tmp/ffmpeg] sudo ifdown -a
34839:algernon@melkor: /tmp/ffmpeg] cvs diff
Unknown host mplayerhq.hu.
[/code:1:dfb82f0458]

Nem muxik ez offline, de nem am :)

Ellenben:

[code:1:dfb82f0458]
34848:algernon@melkor: /tmp/rb-site] tla tree-version; tla archives | grep rhythm
rhythmbox-devel@gnome.org--2004/rb-site--main--0
rhythmbox-devel@gnome.org--2004
http://web.rhythmbox.org/arch/2004
34849:algernon@melkor: /tmp/rb-site] sudo ifdown -a
34850:algernon@melkor: /tmp/rb-site] tla changes
* looking for rhythmbox-devel@gnome.org--2004/rb-site--main--0--base-0 to compare with
* comparing to rhythmbox-devel@gnome.org--2004/rb-site--main--0--base-0
[/code:1:dfb82f0458]

Ez teljesen jol muxik.

[quote:af8eb0fc4b="egmont"][quote:af8eb0fc4b="thuglife"]Most neztem meg. Egy public CVS repon. local checkoutoltam foo -t. persze directoryt adtam meg ezutan problema nelkul megy diff es log is.

Ügyi vagy. Segís légyszi, hogy nekem is menjen.
egmont:~/joe-current$ cvs diff
Unknown host cvs.sourceforge.net.
egmont:~/joe-current$

Jezusom cvs(1) -t olvasd mar el. De mivel látom gyenge vagy man olvasasban ezert inkabb pastolok:

-d CVS_root_directory
Use CVS_root_directory as the root directory path-
name of the master source repository. Overrides
the setting of the CVSROOT environment variable.
This value should be specified as an absolute path-
name.

De nezd meg a CVS/Root file tartalmát és okosabb leszel.

[quote:02d72573df="algernon"][quote:02d72573df="thuglife"][quote:02d72573df="algernon"](Lasd korrekciom: csinald ezt meg ugy, hogy a repo remote gepen van, megis megy offline a diff es a log; Extra bonusz ha offline, commit jog nelkul tudsz taget csinalni [Arch-al ez is megy, local repo felallitasa utan :])

Most neztem meg. Egy public CVS repon. local checkoutoltam foo -t. persze directoryt adtam meg ezutan problema nelkul megy diff es log is.

[code:1:02d72573df]
34837:algernon@melkor: /tmp/ffmpeg] cat CVS/Root
:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg
34838:algernon@melkor: /tmp/ffmpeg] sudo ifdown -a
34839:algernon@melkor: /tmp/ffmpeg] cvs diff
Unknown host mplayerhq.hu.
[/code:1:02d72573df]

Nem muxik ez offline, de nem am :)

Ellenben:

[code:1:02d72573df]
34848:algernon@melkor: /tmp/rb-site] tla tree-version; tla archives | grep rhythm
rhythmbox-devel@gnome.org--2004/rb-site--main--0
rhythmbox-devel@gnome.org--2004
http://web.rhythmbox.org/arch/2004
34849:algernon@melkor: /tmp/rb-site] sudo ifdown -a
34850:algernon@melkor: /tmp/rb-site] tla changes
* looking for rhythmbox-devel@gnome.org--2004/rb-site--main--0--base-0 to compare with
* comparing to rhythmbox-devel@gnome.org--2004/rb-site--main--0--base-0
[/code:1:02d72573df]

Ez teljesen jol muxik.

Sajnos nem nagyon ismerem se SVN -t se arch ot. De gondolom a changelogot is tarolja localba.

[quote:dc1160d249="thuglife"]
Jezusom cvs(1) -t olvasd mar el. De mivel látom gyenge vagy man olvasasban ezert inkabb pastolok:

...

De nezd meg a CVS/Root file tartalmát és okosabb leszel.

Epp ezt probaljuk megvilagitani: itt az a lenyeg, hogy a repo tavol van, offline vagy, diff megis muxik. Lokalis repoval persze hogy megy offline, gaz is lenne, ha nem :P (local mirror a remote repobol nem er, azt arch es svn is tudja, de most nem arrol van szo, hanem minden extra config nelkuli mukodesrol)

[quote:2e037e606e="thuglife"]Sajnos nem nagyon ismerem se SVN -t se arch ot. De gondolom a changelogot is tarolja localba.

Ahogy mondod. Checkoutot verzioval egyutt. (Arch meg olyat is tud hogy az osszes checkoutolt verziot tarolja egy ugynevezett revision libraryban, just in case, amit kezzel meg lehet ritkitani ha tul nagyra none - de nem ez a default)

[quote:9b1c9b9464="algernon"][quote:9b1c9b9464="thuglife"]
Jezusom cvs(1) -t olvasd mar el. De mivel látom gyenge vagy man olvasasban ezert inkabb pastolok:

...

De nezd meg a CVS/Root file tartalmát és okosabb leszel.

Epp ezt probaljuk megvilagitani: itt az a lenyeg, hogy a repo tavol van, offline vagy, diff megis muxik. Lokalis repoval persze hogy megy offline, gaz is lenne, ha nem :P (local mirror a remote repobol nem er, azt arch es svn is tudja, de most nem arrol van szo, hanem minden extra config nelkuli mukodesrol)

Ertem okes. Miertnem ezzel kezdted? :) . Persze arra is van lehetoseg hogy a teljes repot local mirrorozd de persze ahhoz mar kell mas is CVS en kivul.

[quote:220411006d="thuglife"]
Ertem okes. Miertnem ezzel kezdted? :) . Persze arra is van lehetoseg hogy a teljes repot local mirrorozd de persze ahhoz mar kell mas is CVS en kivul.

Szerintem kb ezzel kezdtem, lehet hogy nem voltam eleg vilagos, akkor sorry :)

Mondjuk ha ennyi lenne az osszes kulonbseg cvs es svn/arch kozott, akkor meg mindenki cvst hasznalna, mert ez hasznos meg jo, de kozel sem letfontossagu :) (rename meg arch distributed mivolta mar sokkal inkabb vonzo tulajdonsag az en szememben :)

[quote:60f10f3b9f="algernon"][quote:60f10f3b9f="thuglife"]
Ertem okes. Miertnem ezzel kezdted? :) . Persze arra is van lehetoseg hogy a teljes repot local mirrorozd de persze ahhoz mar kell mas is CVS en kivul.

Szerintem kb ezzel kezdtem, lehet hogy nem voltam eleg vilagos, akkor sorry :)

Mondjuk ha ennyi lenne az osszes kulonbseg cvs es svn/arch kozott, akkor meg mindenki cvst hasznalna, mert ez hasznos meg jo, de kozel sem letfontossagu :) (rename meg arch distributed mivolta mar sokkal inkabb vonzo tulajdonsag az en szememben :)

Persze az is lehet hogy en ertettem felre a dolgot este van mar azert :)
Mh szerintem ez nem teljesen igaz. Az emberek altalaban sokat adnak mas velemenyere es szeretik az uj dolgokat hasznalni. Még akkor is ha nem származik előnyük belőle vagy akár hátrányos is.

Nem akartam uj temat nyitni a kerdesnek, mert talan jol kapcsolodik a fentiekhez.

Egy par honapja teszt jelleggel svn+apache combot hasznalok otthon, verziokovetesre. Nincs nagy forgalom, kicsi repok, egyelore tenyleg csak teszt cellal ment.

A legutobbi apache sebezhetoseg miatti frissites utan a 4 repobol 3 BerkeleyDB hibat ad svnadmin verify-ra, es nem engedelyezi hozzaferest a repohoz. Probaltam svnadmin recover-rel helyrehozni, de miutan egy nehany filebol allo repoval 3-4 ora alatt nem vegzett (a processzor es memoriahasznalaton pedig nem latszott, hogy dolgozna), hat kilottem.

Kerdes:
1. Ugy lattam, hogy masoknak is problemas volt a BerkeleyDB. Van-e tapasztalatotok az svn uj adattarolasi rendszerevel, ami azt hiszem, hogy az 1.3-astol alapertelmezett?

2. Meg lehet-e menteni az adatbazisokat, vagy inkabb mondjak le rola. Nem nagy tragedia, csak azert lenne erdekes, mert ha ilyen modon fontos metaadatok vesznenek el, az megkerdojelezi az egesz verziokovetes ertelmet.

3. Az Arch sok tekintetben szimpatikus, de ha mar valtok, akkor esetleg szoba jonne a Monotone, vagy a Darcs, stb. Van ezekkel tapasztalatotok?

Hat ugy latszik a tema nem valtott ki tul nagy erdeklodest, de azert megprobalom osszegezni, hogy mire jutottam.

Egy nagyon jo feature matrix osszehasonlitas:
http://better-scm.berlios.de/comparison/comparison.html

es egy kicsit alaposabb elemzes:
http://www.dwheeler.com/essays/scm.html

elolvasasa utan, a Monotne latszik befutonak. A legnagyobb hatranya, hogy nincs hozza GUI, ami azert kenyelmes dolog, na meg nem rossz bizonyos dolgokat vizualizalni.
Ugyanakkor a Subversion is nagyon jo eredmenyt ert el az altalam felallitott szempontrendszerben, es ezert az uj fsf tarolasi rendszer meger egy probat mielott atallnek a Monotne-ra.

A GNU Arch eseteben az elemzes sajnos hosszan ecseteli az apro, de annal bosszantobb problemakat, illetve a nem teljeskoru portolhatosagot, igy vegulis kiesett.
A Darcs pedig az elemzes alapjan meg nem jutott el a pruduction stable fazisba, illetve komoly hatranya a Haskell implementacio, raadasul a feature matrix alapjan nincs repository jogosultsagkezelese.

A tobbi resztvevo liszensz okok miatt, vagy egyeb hianyossagok okan mar hamarabb kiszelektalodott.

[quote:d6a78c5f92="fdavid"]1. Ugy lattam, hogy masoknak is problemas volt a BerkeleyDB. Van-e tapasztalatotok az svn uj adattarolasi rendszerevel, ami azt hiszem, hogy az 1.3-astol alapertelmezett?

Az fsfs-re gondolsz, vagy van esetleg valami még újabb? Mi már jó ideje az fsfs-t használjuk, tökéletesen működik.

[quote:5cdb0daf5c="egmont"][quote:5cdb0daf5c="fdavid"]1. Ugy lattam, hogy masoknak is problemas volt a BerkeleyDB. Van-e tapasztalatotok az svn uj adattarolasi rendszerevel, ami azt hiszem, hogy az 1.3-astol alapertelmezett?

Az fsfs-re gondolsz, vagy van esetleg valami még újabb? Mi már jó ideje az fsfs-t használjuk, tökéletesen működik.

Igen az fsfs-re gondoltam. Ugy tudom, hogy csak az 1.3-astol lett ez a default tarolasi mod, ezert vannak az en repoim meg BerkeleyDB-ben.

Mostmar csak az a kerdes, hogy meg lehet-e menteni az eddigi adatbazisokat.

Egyebkent rengeteg elosztott SCM van korai fejlesztesi szakaszban, es eleg igeretesek. Persze az en igenyeimet teljesen kielegiti egy kozponti repository, igaz mar a Subversion kivetelevel nem nagyon fejlesztenek ilyet.

Szoval reszemrol az adatbazisok megmentese majd dumpolasa es loadolasa az fsfs tarolasi rendszerbe lenne az optimalis megoldas.