Verziókezelés - CVS, Subversion, VSS
2006-01-12T23:00:59+01:00
2010-12-09T10:25:55+01:00
2022-07-24T20:56:26+02:00
  • Diffelni barmelyik SCM-el tud, legfeljebb kulso eszkozt hasznal, ha maga az SCM nem ad hozza tamogatast.

    Feltetelezzuk, hogy van egy .sql scriptje ami 0-rol felepiti a DB-t, gondolom ezt akarod diffelni. Mi lesz, ha a fejlesztes soran pl. torol egy tablat..? Csak oda fog jutni, hogy kezzel kell megirnia az inkrementalis modositasokat...
    Mutasd a teljes hozzászólást!
  • Ó dehogynem :). git

    (csak hogy teljes legyen a válasz, a "git apply" segítségével lehet használni az így elkészített patch-et).
    Mutasd a teljes hozzászólást!
  • symfonyban is van ilyen

    Annak ellenére hogy nem használod fejlesztéshez a symfonyt, a változtatások egy bash script segítségével akár automatizálva is átkerülhetnek.
    Mutasd a teljes hozzászólást!
  • SCM-ek ezt nem oldjak meg neked, erre leginkabb a Ruby on Railses >>Migration lenne jo, hasonlo feature-ok vannak pl. >>Codeigniterben.

    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Van egy projektem, ami ki van rakva élesbe is, de folyamatosan folyik rajta a fejlesztés (PHP-MySQL).

    Kéne nekem valami olyan cucc, ami megjegyzi a módosításokat, és esetleg módosítani is tudja a végén az éles adatbázist (ALTER, vagy CREATE TABLE), illetve csak azokat a fájlokat cseréli le amik módosítva voltak.

    A legjobban az kéne, hogy mit módosítottam az adatbázisban tábla szinten, mert a fájlokat felül tudom csapni a régivel, az mindegy, csak az adatbázist nem annyira.

    Ezt meg lehet oldani, valami verziókezelő rendszerrel? Sajnos nem tudom melyik mit tud. (Még nem használtam komolyan soha)
    Mutasd a teljes hozzászólást!
  • Semmi ötlet?
    Mutasd a teljes hozzászólást!
  • Azt tudom, hogy az SVN szerveren van ilyen szolgáltatás.
    A kérdésem az, hogy konkrétan a Google Code-on lehet-e használni ezt a funkcionalitást?

    Amennyire én értem, a linked mögött olvasható svnadmin dump utasítás csak akkor működik, hogyha közvetlenül az SVN szervert működtető gépre vagy bejelentkezve.


    Mutasd a teljes hozzászólást!
  • Jól látom, hogy az SVN projekteket nem lehet backup-olni/restore-olni?
    lehet, de működik a copy is...
    Mutasd a teljes hozzászólást!
  • Használja valaki a Google Code projekt hosztolás szolgáltatást?

    Jól látom, hogy az SVN projekteket nem lehet backup-olni/restore-olni?

    (Nem kritizálás képpen kérdezem, mert egy tök jó szolgáltatás, csak érdekel, hogy nekem kerülte-e valami el a figyelmemet.)
    Mutasd a teljes hozzászólást!
  • Van meg, amit erdemes megnezni: mercurial (Hg):
    "Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive "
    Nekunk bevalt - akar SVN-HG egyutt is jol mukodott. Bar ketsegtelen, ennek is vannak hatranyai, kicsit macerasabb, de sok lehetoseg van benne :)

    Link
    Mutasd a teljes hozzászólást!
  • VSS az felejtős, ha használod, tudod milyen gáz.
    SVN jó, de VS integráció nem tökéletes.
    TFS egészen jó, kicsit más a koncepció mint az SVN-nél, viszont jobb a Studioval, főleg a continous integration-t akarsz.(és miért ne akarnál?:))

    Volt projektünk - az MS-nek kellett bedolgozni- és az MS sem használja a VSS-t :) érdekes.

    Szal nálam a TFS vezet 1 paraszthajszállal.1es kollégák a Perforce-szal nyomták évekig és naon jó véleménnyel vannak róla.
    Mutasd a teljes hozzászólást!
  • CVS + TortoiseCVS kliens + Windiff-el nagyon jól megvagyok/megvagyunk. Na meg persze ott a CVSWeb is.
    Mutasd a teljes hozzászólást!
  • Az SVN a CVS egy fork-ja. Az SVN többet tud, és jobban mint a CVS.
    Pl SVN-ben olcsó, és gyors a branch/tag-elés, tranzakcionális commit van. Az svn-ben könnyen lehet mozgatni file-okat és könyvtárokat, át lehet nevezni teljes history megtartással.

    Az átnevezéssel akkor van probléma, amikor checkout-olsz, majd a local revisionban átnevezel valamit. Commitkor az SVN azt fogja hinni, hogy egy file törlés és egy file létrehozás történt.
    GIT-nél viszont pl ez is jól meg van oldva.


    A lock-modify-unlock csak addig használható, amig kevés módosítás, kevés commitálás van.
    Checkoutolsz egy projectet. Vagy lelockolsz mindent, vagy egyesével lockolgatod azokat a file-okat, amikhez hozzányulsz.
    Eközben a kollégáid nem nagyon tudnak dolgozni.

    A mergelés viszont egyáltalán nem gáz. Az SVN pl automatikusan merge-l file-okat, és csak akkor kell kézzel beavatkozni, ha conflict van. Ilyenkor tulajdonképpen ugyanazt kell megcsinálnod, mintha egy modify unlock után kellene megmódosítanod a file-t.
    Mutasd a teljes hozzászólást!
  • Én Bazaar-t használok - bazaar-vcs.org - tökéletes. Van SVN pluginja is, így be tudsz kapcsolódni SVN-es csapatba is.
    Mutasd a teljes hozzászólást!
  • Ki mit tart ma hatékony eszköznek verziókövetéshez? Elsősorban kis létszámú (<=5 fő) fejlesztő csapatnak.
    Az eddigi listát ki lehetne egészíteni olyanokkal is, mint mercurial, aegis, darcs.
    Mutasd a teljes hozzászólást!
  • Koszi az attekintest. Ennyire vagyok kepben, de masnak biztos jol jon.

    Sajna az svn book csak 1.1-es verziora teljes, de most letoltottem a legujabbat hogy az ilyenekrol mint lock is tudjak. Kosz az infot. Bar nekem ez most csak elmeleti kerdes, mivel 1szemelyes hasznalatra keresek most rendszert.

    A brancs, de meg inkabb a tag-kezelese nem tetszik az svn-nek. Bar igy hogy nehany napja olvasgatok roluk es kozben ulepszik a dolog mar nem annyira unszimpi. De akkor is furcsa ez a "a tag is olyan mint a brancs, csak egy masolat amit felcimkezel, csak masik konyvtarba teszed, tehat a juzer nezopontja miatt lesz a tag tag, a brancs meg brancs".

    SVN: egyetlen dolog nincs rendesen megoldva, a rendes file rename history megorzessel.


    Ezt nem ertem. Pont ez van rendesen megoldva benne! Vagy milyen megoldas kene neked? Mondjuk jobb lenne ha os parancsokkal is lehetne mozgatni es a verziokezelo rajonne magatol hogy mi tortent . Most hogy igy leirtam erre lehet irok majd valami toolt.

    A BitKeeper nem erdekel, Perforce nez ki meg jol, de az tenyleg csak nagyobb cegeknek eri meg.

    A git-re raneztem (nem merultem el benne), de nekem meg a subversion eppen hatareset a fiatalsaga miatt, a git meg fiatalabb es nem latom annyira erosnek (nem jnak, hanem nem latok annyi garanciat arra hogy 5 ev mulva is meglenne rendesen karbantartva).
    Mutasd a teljes hozzászólást!
  • Akkor egy kis attekintes:

    Kezdetben vala az RCS. Ez csak file-okon tamogatta a diffek kezeleset.

    Aztan lett a CVS amivel mar tamogatast adtak arra is hogy directory-hoz hozzaadjal vagy elvegyel fileokat. Ez meg mindig nem ismeri azt az elkepzelest, miszerint egy filenak path-ja is van ami valaha mas is lehetett mint most.

    A SVN mar tamogatja az egesz directory strukturakat.

    Ennyit a torteneti attekintesrol.

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

    Ezenkivul a SVN rengeteg dologgal tud tobbet mint a CVS, es a legtobb muvelet joval gyorsabban van leimplementalva mint a CVS-ben.

    Mellesleg SVN-ben (1.2-tol) mar van lock modify unlock: az elkert lock megakadalyozza hogy mas commit-oljon arra amit te lockolsz.

    Merge: na ez speciel pontosan ugyanugy van mint a cvs-ben: egy osszebarmolt filet kell kijavitani kezzel. Erre persze megvannak a megfelelo eszkozok amik ezt marmar konnyen megoldhatova teszik, de azert meg nem a ClearCase-e a GUI. (Viszont valoszinuleg a ClearCase-et at lehetne emelni , persze licenc kell hogy legalisan csinald)

    Mindenesetre mindkettohoz nem art ha van valami kenyelmes tamogatasod. Mi pl. Subversion-t hasznalunk odabent, az TortoiseSVN-el es kdiff3-al egesz kenyelmesen hasznalhato.

    Eclipse integracio is van mindkettohoz, itt a CVS support nekem kicsit szimpatikusabb, bar nem probaltam azzal merge-elni meg, lehet hogy ugyanolyan kenyelmetlen lenne mint SVN-t mergelni vele. A merge-en meg van javitani valo benne.

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

    A lmu-cmm vitahoz:

    File tipus valogatja: binaris fileokhoz egyertelmuen a lmu javasolt, olyan szinten megtoldva, hogy read-only legyen amig nem lockoltad. Ehhez a CVS semmit nem tud adni, a SVN meg mindent.
    Enelkul meg vagy love amikor mergelni kell.

    Olyan ascii fileokhoz amikhez van jo automatikus merge (ami ismeri is a file szemantikai felepiteset, tehat tud automatikusan szemantikailag is helyeset merge-elni), jo a cmm is.
    Viszont jaj annak aki pl. csak alap text-diff-el probal mergelni egy atrendezett Java filet...

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

    Branch kezeles:

    CVS: konyorgom, mirol beszelunk??? Gyakorlatilag van egy kulon repository-d amiben addig vagy jo, mig nem csinaltal semmi atnevezest (es ami alatt a fo agban szinten nem).

    SVN: egyetlen dolog nincs rendesen megoldva, a rendes file rename history megorzessel.

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

    Egy dolgot meg hozzatennek:

    Ezek mindketten file-alapu verziokezelok. Igazan komplex projekt kezelesere amin sokan dolgoznak, es egyszerre sok fileon kis valtoztatasokat commitolnak be, nem igazan alkalmasak, mivel a valtozasok osszetartozasat nem tudjak kezelni. Hogy a tobb egymastol fuggetlen repository idonkenti lehetoeg automatikus szinkronizalasarol ne is beszeljek.

    Az alternativak a change alapu verziokezelok, amik pont az emlitett igenyekre vannak kihegyezve, ezek egyik legjobb peldaja a BitKeeper. A git-et igazan nem ismerem, nem tudom pontosan hogy mukodik, de arra alltak at a Linux kernel fejlesztoi miutan megszunt az ingyenes BitKeeper.
    Mutasd a teljes hozzászólást!
  • Üdv!

    Mi CVS-t használunk most éppen egy projekthez, és amiért (nekünk) jobb a copy-modify-merge a lockkal szemben az az, hogy még elég béta állapotban vannak a rendszer egyes komponensei, és gyakran van szükség arra, hogy az egyik modul fejlesztője valami apró bugfixet csináljon egy másik modulban, amin lehet, hogy valaki más éppen dolgozik.

    Igazából eddig még sok feloldandó konfliktus nem volt, tipikusan a CVS mondjuk olyan szinten képes magától is összefésülni a dolgokat, ha pl. Java nyelven két különböző metódusban történnek konkurens módosítások. Bár az igaz, hogyha egyszer összemergel két különböző Eclipse plugin-leírót, akkor jó pár órás munka tud lenni a helyes állapot kézi összerakása.

    Igazából én CVS-en kívül mást még nemigazán próbáltam, szóval összehasonlítási alapom nincs, de egyenlőre a CVS-el még nem volt semmi komoly problémánk (igaz, kis projekt, 5-6 fejlesztővel).
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Kérdések:
    CVS valamiben jobb, mint a Subversion? mert rákeresve mindenütt a CVS-ről Svn-re áttérésről írnak. De lehet csak a CVS-nek nem olyan jó a "marketingje"?
    1 oldalt találtam, ahol a CVS az Svn nel szemben felülkerekedik:
    svncvs

    Részemről mindkettőt megnéztem, és pl a banching kezelése a CVS-nek jobban tetszik.

    Más:
    Miért van az, hogy az ingyenesek a copy-modify-merge megoldást támogatják és nem a lock-modify-unlock -ot? VSS-t használunk a melóhelyen és ugyan állítólag gáz (még az ms szerint is :) ), de közepes projekt 10 fő körül szerintem jól elvan a lmu megoldással. Inkább mint mergelni meg conflictokat feloldani diffekkel. Ráadásul ha változik mondjuk a projekt fájl, akkor jobb ha azt is kikérem lockolásra, mintha én is változtatom meg más is, mert aztán ember legyen a talpán aki azt összemergeli!

    Röviden és elsőre ennyi.
    Mutasd a teljes hozzászólást!
abcd