játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5440
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
> 1 <
Pretender - Törzstag | 2498 hsz       Online status #186830   2012.08.28 21:22 GMT+1 óra  
Ja, megvan akkor. Köszi

   
Matzi - Szerkesztő | 2519 hsz       Online status #186815   2012.08.28 15:40 GMT+1 óra  
Érdemesnek érdemes. Csak pár feature használata nehézkes lesz. Pl ha mindent transzformálsz, akkor nem nagyon fogsz tudni különböző branchokat összevonni. Nem lesz szép a verziófa, de ettől még megmarad minden.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
zeller - Törzstag | 464 hsz       Online status #186812   2012.08.28 14:39 GMT+1 óra  
Mindig erdemes verziokovetni. Ha nem akarod elveszteni a munkadat veletlenul. Persze ha lokalis a verziokoveto azon ez nem segit...

   
bolyzsolt - Törzstag | 607 hsz       Online status #186811   2012.08.28 14:35 GMT+1 óra  
Azt ugye jól gondolom, hogy nulláról történő (jelen esetben PHP keretrendszer) fejlesztés esetén, amíg az ember alapjaiban módosítja a forráskódot (könyvtárszerkezet, gyakran töröl/hozzáad fájlokat, szóval még szinte az egész kódtömeg instabil), addig nem érdemes verziókövetni?

   
Matzi - Szerkesztő | 2519 hsz       Online status #186809   2012.08.28 13:44 GMT+1 óra  
A branch egy leágazás, azt tudja, hogy oda amit beraksz, az nem érinti a többi branch-ot. Így nyugodtan fejlesztgethetsz benne, és időnként ha akarod, akkor összevonhatod a branch-okat, azt hívják úgy, hogy merge. A diff meg két fájlverizó összehasonlítása (azonos ágban, de eltérő revízió, vagy akár másik ágból is). Kb ennyi a lényegük.

Még szokott lenni olyan, hogy tag, vagy r-state, vagy label, vagy akármi, ami azt tudja, hogy megjelölsz minden fájlt egy adott revízióban (általában az adott ág összes fájljának a legfrissebb verziója), és így bármikor lehúzhatod az adott állapotot, így megmarad egy korábbi release is tökéletesen.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
DMG - Szerkesztő | 3172 hsz       Online status #186805   2012.08.28 11:26 GMT+1 óra  
Idézet
BlueDeath :
Idézet
sirpalee :
Hasznalj git-et, vagy mercurialt (tudod konvertalni az svn repodat). Az alapbol tamogatja azt a fajta felepitest ami neked kene. (DVCS)



A git undorító


És az íze is szar.
-----------------------------------------
Dont Listen to the Naysayers
   
BlueDeath - Törzstag | 1035 hsz       Online status #186804   2012.08.28 10:36 GMT+1 óra  
Idézet
sirpalee :
Hasznalj git-et, vagy mercurialt (tudod konvertalni az svn repodat). Az alapbol tamogatja azt a fajta felepitest ami neked kene. (DVCS)



A git undorító, svn sokkal jobb
   
Pretender - Törzstag | 2498 hsz       Online status #186801   2012.08.28 09:54 GMT+1 óra  
Valaki röviden, tömören össze tudná foglalni, hogy a verziókövetésben az ilyen főbb parancsok mit jelentenek?
- commit: az én saját kódomat feltöltöm
- update: a repositoryból az utolsó verziót szedem le magamhoz
- revert: visszaállítom magamnak azt a verziót, amit szerkesztés előtt updateltem
Ezeket ismerem svnből, gondolom van megfelelőjük gitben is. Amiket nem ismerek pl.: batch, branch, diff, meg nem is tudom miket szoktak még használni.

szerk.:
Máshogy: jól sejtem, hogy a brach az valami olyasmire való, hogy van egy adott verzióm, és ugye mindig létezik egy master branch, ha commitelek, akkor ez automatikusan az új snapshotra fog mutatni. Azonban tudok olyat csinálni, hogy létrehozok egy új branchet, és ha így commitolok, akkor a master branchom pl. az "marad". Így ha vissza checkoutolok rá, akkor olyan, mintha revertelnék. Vagy valami ilyesmi.

Ezt a hozzászólást Pretender módosította (2012.08.28 10:09 GMT+1 óra, ---)

   
sirpalee - Tag | 1282 hsz       Online status #183200   2012.06.14 12:24 GMT+1 óra  
Ingyenesek persze. Dropboxba szinkronizalast meg felejtsd el, problemakat okozhat ilyen esetben. Ott van a bitbucket, kapsz privat repositoryt, 4 gigaig ingyen. Es azt rajtad kivul senki mas nem eri el
(ha ugy allitod be).
raytraceisten és übermedic
   
Pretender - Törzstag | 2498 hsz       Online status #183194   2012.06.14 10:22 GMT+1 óra  
Megnézem, remélem ingyenesek is köszi

   
sirpalee - Tag | 1282 hsz       Online status #183187   2012.06.14 09:23 GMT+1 óra  
Hasznalj git-et, vagy mercurialt (tudod konvertalni az svn repodat). Az alapbol tamogatja azt a fajta felepitest ami neked kene. (DVCS)
raytraceisten és übermedic
   
Pretender - Törzstag | 2498 hsz       Online status #183185   2012.06.14 09:12 GMT+1 óra  
Mert most miért? Simán lehet ilyet valahogy Ha meg ennyire nagyokos vagy, akkor már meg is írhattad volna, hogy miért jó / miért nem jó / miért (nem) lehet ilyet, de az ilyen hozzászólásokat inkább mellőzd, nem vagyok rá kíváncsi köszi.

   
Omega - Tag | 70 hsz       Online status #183182   2012.06.14 08:53 GMT+1 óra  
Ez most komoly akart lenni?

   
Pretender - Törzstag | 2498 hsz       Online status #183159   2012.06.14 07:09 GMT+1 óra  
Fú, van egy ilyen régi topic No az lenne az elképzelés, hogy van egy Dropbox accountom, meg egy VisualSVN Serverem. Azt kellene valahogy megcsinálni, hogy ne lokálisan legyen verziókövetve, hanem a saját kis dropbox cuccomba is bemásolja. Ehhez csak annyit kell tenni, hogy amikor beállítom a Repository pathet a VisualSVN Servernél, akkor a dropbox mappám egyik mappáját adom meg? Szóval elég, ha csak azt szinkronizálja, abban benne van a tényleges kód, ugye?

szerk.:
Csak mert valahogy nehéz elképzelni, h 400kb-ba belefér az egész..

Ezt a hozzászólást Pretender módosította (2012.06.14 07:20 GMT+1 óra, ---)

   
Quantum - Tag | 30 hsz       Online status #140878   2010.09.13 11:36 GMT+1 óra  
Na, mivel megoldódott, gondoltam elmondom a megoldást, hátha esetleg más is járna így a közeljövőben.
A Projekt.vcproj fájlban van két sor, amik így kezdődnek: inheritedPropertySheets="". A két idézőjel között a "\Microsoft Visual Studio 9.0\VC\VCProjectDefaults\UpgradeFromVC60.vsprops" elérése van megadva, ez pedig alapértelmezetten a Program Files-ban van. Ezt a két sort egyszerűen ki kell törölni és nem lesz többé ilyen gond. Ha egy új projektet hozunk létre, azokban alapból nincs meg ez a két sor.
Remélem segítség volt azoknak, akik a jövőben ezzel fognak találkozni.

   
Kuz - Törzstag | 4455 hsz       Online status #140710   2010.09.09 11:46 GMT+1 óra  
+1 kicsy hsz-éhez. Csak azt küldi el, amit Te bent hagysz. Mi is jórészt tortoise-t használunk a cégnél, és néha van is belőle vita, hogy ki-mit-miért commitolt fel.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Quantum - Tag | 30 hsz       Online status #140709   2010.09.09 10:38 GMT+1 óra  
Köszi, hogy válaszoltatok.
Az ignore-t megtaláltam közbe, de gondoltam én is rá, hogy nem kéne, az általad leírtak miatt.
Viszont ha leveszem a pipát, mikor feltöltöm a "nem kívánatos fileok előtt", a project fájlt akkor is elküldi. És szomorú, hogy az elérési utat ( InheritedPropertySheets="E:\Programs\Microsoft Visual Studio 9.0\VC\VCProjectDefaults\UpgradeFromVC60.vsprops" ) mindig megváltoztatja, tehát megint át kell írni mindent. Most veszem azonban észre, hogy érzékeli, hogy konfliktus helyzet állt elő, megmutatja, hogy a haver gépén hogy néz ki a fájl, mellette ott van az enyém is, csak nem tudja merge-lni.
Ez a helyzet már csak azért is szomorú, mert csak ennél az egy projektnél csinálja ezt, máskor sosincs semmi baj a projekt fájlokkal.

   
miso - Tag | 15 hsz       Online status #140707   2010.09.09 08:27 GMT+1 óra  
Tortoise svn-nél commit esetén a tényleges feltöltés előtt kiírja a megváltozott file-ok listáját a verziókezelő, s szépen vissza lehet venni a pipákat a project file-ok, exe-k és nem kívánatos fileok előtt.

A VisualSVN-t nem ismerem, de a tortoise svn biztos, hogy nem tölti fel a project filet, ha uncheckeled.
Ami már fel lett töltve meg ugye törlendő, különben updatekor mindig újra leszeded a fent lévőt.

Ezt a hozzászólást miso módosította (2010.09.09 08:37 GMT+1 óra, ---)

   
kicsy - Szerkesztő | 4304 hsz       Online status #140703   2010.09.09 00:57 GMT+1 óra  
What? A project fájlban biztosan nincsenek abszolút elérési utak. Gép és felhasználó-specifikus dolgok, beállítások a solution-höz tartozó .suo fájlban lehetnek.
A megoldás pedig az ignore nevű fícsör, gondolom visualsvn-ből is megy, tortoisesvn-ből biztos, jobbklikk a fájlon, tortoisesvn->add to ignore list, vagy delete and add to ignore list, ha már verziókövetve van. Ezt igazából minden generált részre kéne alkalmazni, szóval a bin könyvtárat, object fájlokat és hasonlókat illik ignore-ra tenni.
A vcproj fájlt viszont ne, abban vannak a project beállításai, és hogy milyen fájlok vannak benne egyáltalán. Ha nem verziózzátok, pont hogy akkor kell mindenkinél kézzel hozzáadogatni például az új fájlokat.
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
Quantum - Tag | 30 hsz       Online status #140701   2010.09.09 00:34 GMT+1 óra  
VisualSVN kérte, hogy tegyem fel ezt a Tortoise-t, így nekem is ez van.
Az volna a kérdésem, hogy miért van az, hogy mindig el akarja küldeni a projekt fájlt (*.vcproj)? Nagyon bosszantó, mert ahányan dolgozunk, annyi féle helyre van telepítve a Visual Studio, így mindegy egyes update után át kell írni ezt a fájlt, így az változott az új verzióban és a következő commit esetén küldi is az adatbázisra, még akkor is, ha leveszem a pipát, mikor elküldöm. Van erre valami megoldás?

   
miso - Tag | 15 hsz       Online status #140535   2010.09.06 09:42 GMT+1 óra  
Tortoise SVN-t használok. Open source projectekhez a google is ad 2 gigás tárhelyeket, free.

http://code.google.com/intl/hu-HU/

Szerk: Na jól van, a listát csak most nézem, benne van ez is. Nem vagyok ma a toppon.

Ezt a hozzászólást miso módosította (2010.09.06 21:38 GMT+1 óra, ---)

   
Quantum - Tag | 30 hsz       Online status #140339   2010.09.03 17:48 GMT+1 óra  
Sziasztok!
Valamelyikőtök ért a VisualSVN-hez? Van egy kis gondom vele.

   
gymisi - Törzstag | 212 hsz       Online status #34617   2006.10.31 08:28 GMT+1 óra  
Köszi a címet

   
kicsy - Szerkesztő | 4304 hsz       Online status #34604   2006.10.31 07:50 GMT+1 óra  
Itt van egy kisebb lista, meg lentebb Kami is belinkelt egyet.
http://dmoz.org/Computers/Open_Source/Hosting/
Ha nem ragaszkodsz a cvs-hez, akkor a szintén említett https://opensvn.csie.org/ -ot ajánlom.
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
gymisi - Törzstag | 212 hsz       Online status #34600   2006.10.31 07:41 GMT+1 óra  
Valaki esetleg tud mondani, valami ingyenes cvs szervert? ( régebben a http://freepository.com/-ot használtam, de az már ingyenesen nem támogatja a direkt elérést)

   
Orphy - Törzstag | 1893 hsz       Online status #28909   2006.08.31 21:46 GMT+1 óra  
Köszi szépen, így már menni fog!
   
kicsy - Szerkesztő | 4304 hsz       Online status #28824   2006.08.31 04:15 GMT+1 óra  
Ezt tudom ajánlani:
https://opensvn.csie.org/
Jó, gyors, free.
Vmi egyetemi project asszem, és free is marad az idők végezetéig (legalábbis ez a terv )
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
kiskami - Tag | 265 hsz       Online status #28802   2006.08.30 23:56 GMT+1 óra  
Itt egy lista pl.: http://weblogs.asp.net/fmarguerie/archive/2005/04/27/404793.aspx
De a Subverson honlapján is van a linkek között ilyen gyűjtemény ( http://subversion.tigris.org/links.html )
[Silent Vertigo] { Solarah }
http://www.silentvertigo.hu
   
Lexx - Tag | 117 hsz       Online status #28800   2006.08.30 23:38 GMT+1 óra  
"Note: Since November 26 2005, Code::Blocks' repository is under Subversion control at BerliOS. Although the CVS repository still exists at sourceforge.net, we are not using it."

http://developer.berlios.de/

"BerliOS Developer ist ein freier Dienst für Open Source Entwickler und bietet einfachen Zugang zum Besten aus CVS/SVN, Mailinglisten, Bug-Tracking, Diskussionsforen, Aufgabenverwaltung, Webhosting, dauerhafte Dateiarchivierung, Backups und vollständige Verwaltung per Web-Interface."
   
Lexx - Tag | 117 hsz       Online status #28799   2006.08.30 23:35 GMT+1 óra  
A code::blocks tudtommal valami ilyesmin mgy, nézd meg nálu, hogy hol van a szerverük
   
Orphy - Törzstag | 1893 hsz       Online status #28797   2006.08.30 23:23 GMT+1 óra  
valami olyasmi nincsen Subversion-nál, mint a CVS-nél?
Mármint, hogy bereggelek egy tárhelyet neten, és utána oda tenném a repositiory-t?

Esetleg a CVS tárhelyünket fel tudnánk használni erre valami értelmes módon?
A kapott CVS root stringünkkel hiába próbálkoztam a Tortuise SVN-nél

Bocs, tudom, h hülyéket kérdezek, csak a cégnél belső hálós SourceSafe van, a CVS és SVN netes megoldással még kissé új
   
Lexx - Tag | 117 hsz       Online status #28796   2006.08.30 22:58 GMT+1 óra  
A dinamikus ip megoldható, próbáld ki a dyndns -t. Esetleg elegendő, ha megállapodtok egy fix időpontban amikor lehet probálkozni. Már dolgoztam igy egy cégnél (hehe nekik sem volt fix ip-jük) kibirható.
   
Orphy - Törzstag | 1893 hsz       Online status #28786   2006.08.30 15:48 GMT+1 óra  
Kellene még help:

olyan helyet keresünk neten, ahová fel tudnánk tenni az SVC repo-t, lehetőleg ingyenes.
Egyelőre sajnos nem túl sok sikerrel keresgélünk.

Szervert saját gépre nem szeretnék, dinamikus ip-vel és nem állandóan bekapcsolt géppel kissé macerás lenne...

Előre is köszi!
   
Orphy - Törzstag | 1893 hsz       Online status #28678   2006.08.30 02:39 GMT+1 óra  
Köszi a helyesbítést, mindig tanul valami újat az ember...
A linkeket és a doksit megnézem, ha hazaértem, biztosan sokat fog segíteni
   
kicsy - Szerkesztő | 4304 hsz       Online status #28650   2006.08.30 02:01 GMT+1 óra  
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
kiskami - Tag | 265 hsz       Online status #28620   2006.08.29 23:39 GMT+1 óra  
Egy-két dolgot szeretnék helyesbíteni, mert nem egészen az a helyzet, amit leírtál.

Először is, nem csak központosított verziókövető rendszerek vannak, hanem elosztottak is. Ez azt jelenti, hogy nincsen egy központi tár (vagy adatbázis, ahogy tetszik), hanem minden fejlesztő saját, teljes értékű verziókövetett tárral rendelkezik. A fejlesztők egymás repói között, patch-ek formájában szinkronizálják a munkájukat, de lehetnek központinak kinevezett repók is, ahova mindenki küld módosításokat.

Hogy valaki a központosított vagy a nem központosított rendszereket szereti az hitvita kérdése is, mint ahogy az is, hogy fejlettebb-e az a rendszer, amely támogat kizárólagos lefoglalást vagy nem. A lokkolás használata azért nem biztos, hogy a hatékony munkát segíti.

Az a rendszer inkább primitívnek mondható az én szememben, amelyben el tud veszni munka azért, mert kettő vagy több fejlesztő ugyanazon a fájlon dolgozott, és ennek elkerülésére lock-olni kell. Ennek kiküszöbölésére, és a párhuzamos munka támogatására azért már szinte mindenhol támogatott valamilyen összefésülési eljárás (merge) és konfliktuskezelés is. Az igazi finomságok ott vannak, hogy milyen esetekben képes a rendszer magától össszefésülni és követni, ugyanazon erőforráson végzett párhuzamos módosításokat.

Egy-két jó kiindulópont a témában:
http://better-scm.berlios.de/comparison/comparison.html
http://zooko.com/revision_control_quick_ref.html
http://en.wikipedia.org/wiki/List_of_revision_control_software
http://www.dwheeler.com/essays/scm.html

(Én Subversion-t és darcs-ot használok.)
[Silent Vertigo] { Solarah }
http://www.silentvertigo.hu
   
Orphy - Törzstag | 1893 hsz       Online status #28584   2006.08.29 15:11 GMT+1 óra  
Sziasztok,

ebben a topic-ban a verziókövető rendszerekről lesz szó.

Aki esetleg még nem találkozott ilyennel: röviden arról van szó, hogy a program file-jait egy közös adatbázisban a rendszer nyilvántartja, és azokhoz az erre jogosult fejlesztők hozzáférhetnek - így a szervezett, és csapatmunka egyik elengedhetetlen kelléke manapság nagyobb projektek esetén.
A jobb rendszerekben a dolog nem csak erről szól: a rendszer nem hagyja, hogy egyszerre többen is dolgozzanak egy file-on, hiszen így csak az utoljára beküldött módosítás maradna meg, holott lehet, hogy közben a file másik részén egy másik fejlesztő dolgozott - enélkül az ő munkája elveszne. Egy ilyen rendszer pl az MS Visual SourceSafe is.

Van persze kérdés is:

a Gp-nknél tervezünk használni ilyen rendszert, nevezetesen az ingyenes Tortuise CVS-t (http://www.tortoisecvs.org/), és a Tortuise SVN-t (http://tortoisesvn.net/) nézegettük, nekem utóbbi szimpatikusabb, mert láttam benne check-in/check-out-ot, míg az előzőnél nem...
Viszont akadt kis nehézségünk vele: és kicsit szűkszavú az oldal...

Ha valaki már kicsit komolyabban benne van, várjuk a segítségét,
a topic-ba pedig minden olyan infót, ami ezekkel a rendszerekkel kapcsolatos:

linkek, tippek, tapasztalatok, stb.
   
> 1 <