|
|
Ja, megvan akkor. Köszi
|
|
|
É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.
|
|
|
Mindig erdemes verziokovetni. Ha nem akarod elveszteni a munkadat veletlenul. Persze ha lokalis a verziokoveto azon ez nem segit...
|
|
|
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?
|
|
|
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.
|
|
|
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
|
|
|
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
|
|
|
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, ---)
|
|
|
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
|
|
|
Megnézem, remélem ingyenesek is  köszi
|
|
|
Hasznalj git-et, vagy mercurialt (tudod konvertalni az svn repodat). Az alapbol tamogatja azt a fajta felepitest ami neked kene. (DVCS)
raytraceisten és übermedic
|
|
|
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.
|
|
|
Ez most komoly akart lenni?
|
|
|
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, ---)
|
|
|
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.
|
|
|
+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???
|
|
|
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.
|
|
|
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, ---)
|
|
|
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.
|
|
|
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?
|
|
|
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, ---)
|
|
|
Sziasztok!
Valamelyikőtök ért a VisualSVN-hez? Van egy kis gondom vele.
|
|
|
Köszi a címet
|
|
|
|
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)
|
|
|
Köszi szépen, így már menni fog!
|
|
|
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  )
|
|
|
|
"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."
|
|
|
A code::blocks tudtommal valami ilyesmin mgy, nézd meg nálu, hogy hol van a szerverük
|
|
|
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
|
|
|
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ó.
|
|
|
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!
|
|
|
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
|
|
|
|
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.)
|
|
|
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.
|
|
|
Legújabb project:
Szókirakó 3
Legutóbb frissített project:
Szókirakó 3
Friss kép a galériából:
|