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.

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.

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.

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.

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).

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)

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..

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.

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.

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.

Sziasztok!
Valamelyikőtök ért a VisualSVN-hez? Van egy kis gondom vele.

Köszi a címet

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.

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 )

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 )

"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

És persze kami SVN-doksija:
http://jatekfejlesztes.hu/README-Subversion.doc

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.