Szuper írás!
Köszönet érte.

"Légy olyan, mint bárki más, tégy olyat, mint senki más."

Ebben a témában nekem házit kellett írnom az őszi félévben, ami
itt olvasható.
Ennek talán főleg a bevezető, általános része meg az összefoglalója lehet hasznos kiegészítés a jelen cikkhez.

Megbízhatóságom: http://phmegbizhatosag.atw.hu/phtabla.php?nev=Wyll

Első átfutásra jó írás, de azért a profi eszközök között alternatívaként ott van még a Microsoft-féle Team Foundation Server is.

[ Szerkesztve ]

Visual Studio-ba épülő igen hasznos verziókövetőrendszer az ingyenes AnkhSVN is. Nem kell hozzá tortoise, ha nem akarod feltenni, én a kettőt együtt használom, egyszer ajánlatos kipróbálni legalább, VisualSVN-t szerintem lenyomja (már).

//developer

Én a verziókövetés problémájával a Dropbox kapcsán találkoztam először, és nem is igazán értettem meg, hogy ott mi történik, amikor pl. egy docx fájlt ketten szerkesztünk, és mentjük. Erről van vmi bővebb infó?

Steam: marcias88

Köszi.

https://www.coreinfinity.tech

Bravo!
TortoiseSVN-nel való ismeretségemnek hála autodidakta módon, de sikerült kikövetkeztetnem a dolgokat. Köszönhetően a cikknek, most már minden világos, amit eddig csak sejt(h)ettem.
Üdv: Malwy

Szuper írás!

ha jó az angolod érdemes lehet jelentkezned esetleg a sigma kudoshoz vagy az SDI hoz.

dolgoztam az 1ik cégnél szakszövegíróként svntrtuise-el és hát ja. nem volt egy kellemes émény eléggé macerás tooljai vannak a szakmának. a cikk nagyon tetszik. kicsit belemehetnél mélyebben

Liverpool, Chelsea, Arsenal MEZEK ELADÓAK!!!...................http://hardverapro.hu/apro/angol_behozatalbol_mezek_eladoak_liverpool-chelsea/friss.html#msg5

Nem olvastam még, de hasznosnak tűnik.

Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!

Nagyon hasznos cikk, eltekintve hogy csak a végén szólsz arról, hogy van egy olyan operációs rendszerre is, amit nem csak az emberek 2%-a használ. Esetleg illene megemlíteni a Silk SVN-t. Inkább arról kellene még írni, hogy a google rendszerét hogyan lehet beállítani, és működésre bírni a teknőccel, mert nagyon nem triviális.

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

Az ingyenes Sharepoint a legjobb, ha dokumentumokról, csoportmunkáról van szó. Hátránya, hogy hiába ingyenes, ha kell hozzá egy rohadt drága MS Windows 2008 szerver oprendszer....

Én kérek elnézést!

A cikk jó. Szerintem a földgömb ikont nyugodtan hagyd le, a verziókövetés alapból feltételezi, hogy van egy kliens gép meg egy szerver gép és a kettő között adatok jönnek-mennek, ezt nem kell szerintem külön kiemelni.

A fogalommagyarázatba bekerülhet a lock-olás is, mert ugye ha ketten dolgoztok valamilyen bináris file-on, akkor a conflict kb. garantált, ezért jó lockolni.

Alternatívákhoz meg bekerülhetnének fizetős cuccok is, pl. Perforce.

Igazából nem feltétlen szükséges. Az ember a saját munkáját is verziókövetheti, helyi repóval, van hogy hasznos.

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

Ha ezt arra mondtad, hogy a végén említettem meg a TortoiseSVN-t, akkor elmondom, miért történt így:

Azért, mert szerettem volna az elején tisztázni mit jelent egy-két állapot, mi az SVN, mik a parancsok. Ha ezt tudod, akkor bármelyik GUI programban megtalálod azt amit keresel (mivel ott is ugyanazok a parancsok, csak van alá téve egy GUI).

A TortoiseSVN kézikönyve egyébként nagyon hasznos. A Slik SVN tényleg jó, bár Windows alatt sosem tudtam igazán hozzászokni a parancssorhoz. Az egész intézőbe/Total Commanderbe való integráció miatt a TSVN nagyon bevált, igazi göngyszem. Szintén a Tortoise fejlesztői készítik a NaughtySVN nevű alkalmazást, ez gyakorlatilag TSVN Linux alatt, nautilus integrációval, GUI-val, egyszóval minden, amit a TSVN tud, csak Linux alá.

A Google rendszere alatt mit értesz? HTTPS-ral kell checkoutolni majd a legelső commitkor megadni a usernevet. Vagy a zárolásra gondolsz? Az GC-ben nincs bent.

Hát végül is követheti, bár így látatlanban inkább bohóckodásnak tűnik, mint a munkafolyamat hasznos elemének.

[ Szerkesztve ]

Téves feltételezés. Egyrészt, az embert motiválja egy minimális, egészséges szintű adminisztrációra, másfelől biztonsági szempontból is kifejezetten előnyös, mert egyfajta archiválást is megvalósít. Ugyanakkor egy esetleges új fejlesztő csatlakozását is megkönnyíti egy projekthez. Ma már otthon sem kezdek el verziókövető nélkül egyetlen projektet sem, legyen annak eszköze CVS, SVN, vagy bármi más.

Próbáld ki. Csak egy egyszerű projektet csinálj RCS rendszerrel, utána nem fogod tudni elképzelni, hogy éltél nélküle (akár egyszemélyes projektek vitelekor). Nagy projekteknél pedig megsokszorozza a hasznát, asszem ez triviális...

Egy dolog: commit log-ot mindenképp tessék írni! Magadnak könnyíted meg vele az egészet.

[ Szerkesztve ]

Építs kötélhidat  -  https://u3d.as/3078

Leginkább ez a bajom:
Commit
Commit failed (details follow):
Server sent unexpected return value (405 Method Not Allowed) in response to
MKACTIVITY request for '/svn/!svn/act/17796d68-4804-9243-b2bb-eeb5749b432e'
Nem lehet commitolni semmit, valahogy autentikálni kellene magam, de foglamam sincs hogyan.

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

Jó, beismerem ezt jól benéztem. Van egy ilyen gomb, hogy a mercurial vagy svn-t szeretnénk használni, és nem az svn a default. Kár hogy ennyire elrejtették.

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

Jó lett a cikk, bár az SVN-nel azért nagyobb környezetben elég sokat lehet szívni. Főleg akkor, ha fájl szintű és VS alóli mókolás is zajlik. A Git értelmesebbnek tűnik.

Szívesen olvasnék az online svn hosting szolgáltatásokról. Pl code.google.com

Hát, elég nagy környezetben vagyunk, és svn-el semmi bajunk. Sőt örülünk, hogy van Milyen problémák lépnek fel nálatok?

Az szerintem csak azért lehet, mert nem használtatok mást, jobbat.
Én SVN előtt ClearCase-t használtam, azután az SVN összegányolt tákolmánynak tűnik (egyébként tényleg az, az eleve nem túl kitalált, ősi CVS-t patchelgették, abból lett). Eleve a branchek kezelése, a merge, a dynamic view (ez gyakorlatilag egy virtuális filerendszer, amiben a repository aktuális állapota látszik) hiánya, az, hogy a metainfo a filerendszerbe van belekeverve, hogy nem lehet rendesen konfigurálni, hogy mit akarsz látni, stb, stb.

[ Szerkesztve ]

DRM is theft

És folytatnám a sort: a merge tényleg elég gáz, de ha törlök egy fájlt VS alól, azt utána az esetek nagy hányadában nem hajlandó észlelni és nem lehet becsekkolni a projektet. Ilyenkor kezdődik az anyázás, ha ez a nap végén jön. Azon kívül ékezettel írt kommenteket nem lehet migrálni (érthetetlen), de a konfliktok a legszörnyűbbek, amikor magától kidekorálja a kódot. Sok szempontból a git ennél jóval kulturáltabb.

Persze használta VSS-t is, az meg a másik gyönyörűség.

Tényleg jó írás, de a leghasznosabb az lenne (bár lehet hogy csak számomra ), ha összehasonlítanád a különböző verziókövetőket, mik a különbségek működésben, használatban. Én pl. tervezem, hogy a most induló projektemet egyszerre fogom hosztolni launchpad-en, githubon és google code-on is, aminek gyakorlati haszna egyáltalán nincs, sőt csak lelassít, de sztem lehet belőle tanulni elég sokat.

Nekem egyébként pont a ClearCase, ami nagyon megfeküdte a gyomrom, git után . De ez egyébként ízlés dolga is, hogyha az ember megszokja az adott verziókövető logikáját, utána már az tűnik természetesnek, a többi pedig furának.

[ Szerkesztve ]

Azért az SVN nem a git meg a clearcase kategóriája: az a baj, hogy az SVN-nek alapvető koncepcionális hiányosságai vannak, ott azért már nem csak izlésről van szó.

"Tényleg jó írás, de a leghasznosabb az lenne (bár lehet hogy csak számomra ), ha összehasonlítanád a különböző verziókövetőket, mik a különbségek működésben, használatban."

Az a baj, hogy értelmes eredményhez párhuzamosan kellene használni egy csomót a valós életben, hosszabb ideig, ez meg gyakorlatilag kivitelezhetetlen.

DRM is theft

Ha a git után előrelépésként értékeled az SVN-t, akkor vagy kis projektjeid vannak vagy kevesen dolgoztok együtt - vagy csak doksikat tároltok repoban. Nem bántás, ne úgy vedd.

Egyéb lehetőségek közül nagyon hiányolom a CSV-t (Linuxon is van), illetve a MS-világban a Visual Studio Team System-et.

Az svn-nél talán érdemes megemlíteni, hogy az 1.7-es verziótól kezdve változott a local repository. Már nem hányják tele a könyvtárakat .svn alkönyvtárakkal, hanem központi, adatbázis-alapú tárolás van. Nagyságrendekkel gyorsabb.

A tej élet, erő, egészség.

A CVS-nek legfeljebb a történelmi áttekintésben juthatna helye, nagyon régi, nagyon elavult.

DRM is theft

3 éve használom én is napi szinten (3 ország, 100 programozó) az svn-t, és ha értesz hozzá egy kicsit, egyébb fejlesztőkerettel (netbeans, eclips), akkor gond nélkül lehet használni.

A merge nálunk volt hogy felcserélt sorokat, elég nagy gabaly lett belőle.

Törlés: ne VS alól töröld, hanem jobbklikk és SVN delete, az úgy működik.

Ékezettel komment???? Mióta van az angolban ékezetes karakter?

Konfliktok: ha olyan file-nál van, aminek van szerkesztője nekie, akkor szintén jobbklikk, és resolve conflicts vagy valami hasonló. Feldob egy szerkesztőt, kiválasztod melyik kód kell, és eltűnik a sorminta.
Ja és sosem nyomunk rá a "resolved" gombra, annál még az is jobb ha törlöd a file-t kicsekkolod újra, és újraírod amit csináltál.

Jó az ha tudod használni.

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

Ne VS alól töröljek... jó kifogás, de akkor minek az integráció? Nyilván megoldható, nem azt írtam, hogy nem.

"Mióta van az angolban ékezetes karakter?"

Szerintem nem egyről beszélünk... ha check-in van, oda miért ne írhatnám be magyarul, amit akarok? Ez nem az én anyanyelvem butasága, hanem a cuccé, nemdebár? Oroszul is írhatnám vagy kínaiul.

"Feldob egy szerkesztőt, kiválasztod melyik kód kell, és eltűnik a sorminta."

Vagy marad az, hogy most a három kolléga kódjának összehasonlítása tartalomra és kitalálni, melyik működik majd. Igaz, nem kell szuperclassokat írni, de vannak 10 sornál hosszabb fájlok és bizony ez elég zavaró tud lenni. Mondjuk ritkán ütközök már ilyenbe.

"kicsekkolod újra, és újraírod amit csináltál."

Hát ez sem épp felhasználóbarát működés.

"Jó az ha tudod használni."

Nem mondtam, hogy nem jó, használom is, de van jobb is.

[ Szerkesztve ]

"ha check-in van, oda miért ne írhatnám be magyarul, amit akarok?"

Hogy ne vegyel fel rossz szokasokat

"Vagy marad az, hogy most a három kolléga kódjának összehasonlítása tartalomra és kitalálni, melyik működik majd."

Hat, ez inkabb munkaszervezesi problemanak tunik, de igen, ha conflict van, akkor tulajdunkeppen ezt kell csinalnod. Mondjuk merge-nel akkor is lehetnek konfliktusok, ha nem trivialisan ellentmondoak a valtoztatasok, mert oke, azt, hogy ha az "a = x+1" az egyik ember szerint arra valtozik, hogy "a = x+2", a masik szerint meg "a = x+3", az conflictkent jelenik meg, de siman elofordulhatnak olyan valtozasokat, amiket siman osszefesul a merge, csak a kod nem fog mukodni. Ezzel tul sok okosat nem lehet kezdeni, meg kell probalni minel inkabb szetvalasztani az egyes emberek munkajat, ha meg ugyanazt a kodot turjak, akkor meg "merge early, merge often"

DRM is theft

"Hogy ne vegyel fel rossz szokasokat"

\o/

"Hat, ez inkabb munkaszervezesi problemanak tunik"

Szerencsére már ritkán futok ilyenbe, de azért néha megesik. Ilyenkor meg lehet vakarózni, hogy akkor most mi legyen.

Nem nagyon szeretem az SVN-t, de a régi VSS-t azért örömmel cseréltem le erre.

[ Szerkesztve ]

Nem VS alól használtam (hurrá) mert nem x86-ra fejlesztettünk. de valahogy sosem bíztam abban, hogy egy külső cég minden funkcióját jól be tudná integrálni a MS.

Nem tudom nálatok mi a szokás, de szerintem régi szokás szerint körmöst kellene adni annak, aki angol nyelven kívül ír a programkódba, kapcsolási rajzra, műszaki rajzra, ésatöbbi ...

Igazából a merge akkor nem szokott jól működni, ha átfedés van a két átírt kód között. Az pedig azt jelenti, hogy valamit kétszer írnak át, ami tényleg munkaszervezési gond. Ha ez egy bug, akkor bugtrackert kellene használni, ha meg egyszerre dolgozik mindenki mindenen, akkor pedig szét kellene szedni kisebb elemi fileokra, és vezetni valahogy hogy ki min dolgozik.

"Hát ez sem épp felhasználóbarát működés." igen, de így nem vágod haza mindenki más munkáját egy konfliktolt verzió feltöltésével.

[ Szerkesztve ]

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

Mondjuk egy teljesen magyar fejlesztőcég mi a fenének kommentezne angolul, amikor az alkalmazottak jó része nem is ért annyira angolul, hogy írásban helyesen kifejezze magát? Hogy aztán jó nagy félreértések, tévedések és hibák legyenek abból, hogy "hát, én úgy értettem ezt a mondatot, hogy..."

Merge-re normális munkaszervezés mellett is sor kerülhet. Amikor anno egy nagyobb programot írtunk újra, a mi csoportunk csak egy modullal foglalkozott. Viszont az abból meghívott dolgokat meg más csoportok írták át. Így simán előfordulhatott, hogy mi mondjuk átraktunk egy kódrészletet egy másik metódusba, de közben a belőlünk meghívott modul gazdái átneveztek vagy átparamétereztek valamit.

A te módszered az lényegében az a megoldás, amikor lényegében zárolsz egy file-t, amin dolgozni akarsz, és addig más nem nyúlhat bele, amíg az nálad van. Ütközés így is lesz, csak nem nálad, hanem aki utánad akar belemásolni. Hidd el nekem, semmivel sem jobb módszer. (Az egyik nagy céges munkahelyemen ez ment, amíg észre nem tértek.)

Merge-nél annyit tehetsz, hogy minél okosabb (és háromutas) komparáló programot használsz az összefésüléshez.

A tej élet, erő, egészség.

"Mondjuk egy teljesen magyar fejlesztőcég mi a fenének kommentezne angolul, amikor az alkalmazottak jó része nem is ért annyira angolul, hogy írásban helyesen kifejezze magát?"

Nem tudom, nekem mindig furcsák a nem angol kommentek (talán tizenkét éves koromban kommentelem utoljára magyarul - C64-es BASIC-ben ), az meg mondjuk elég nagy szégyen, ha egy fejlesztő nem tud angolul.

"Merge-re normális munkaszervezés mellett is sor kerülhet."

Nem csak hogy kerülhet, hanem tulajdonképpen elkerülhetetlen. Ellenben conflictoknak nem nagyon kellene lenniük.

"simán előfordulhatott, hogy mi mondjuk átraktunk egy kódrészletet egy másik metódusba, de közben a belőlünk meghívott modul gazdái átneveztek vagy átparamétereztek valamit."

Ez tök normális, ebből nem lesz merge conflict, max. nem fordul le a kód

"lényegében zárolsz egy file-t, amin dolgozni akarsz, és addig más nem nyúlhat bele, amíg az nálad van"

Igen, ez a normális, sőt az a normális, ha igazán nem is kell belenyúlnia.

Kivételek persze mindig vannak, de ha folyamatosan gond a merge conflict, az tutira szervezési gond.

[ Szerkesztve ]

DRM is theft

Én csak példákat hoztam fel arra, hogy nem tökéletes. A munkaszervezés nem az svn hatóköre, de vannak olyan esetek, amiket más hasonló rendszerek jobban kezelnek. Ide akartam kilyukadni.

és dabadab:

"az meg mondjuk elég nagy szégyen, ha egy fejlesztő nem tud angolul."

Látom, a kommenten leragadtatok, de nem, a kódba nem írok kommentet (feleslegesnek tartom, a kód beszéljen önmagáért). Se angolt, se magyart. Ha nem angol környezetű multiról beszélünk, akkor pedig magyart írnék, minek erőlködjek például egy iratkezelő rendszernél angol szakkifejezésekkel, amiket másnak is keresgélnie kell, hogy tudja, mit írtam. Vannak azért nem triviális esetek, amikor az angol hátráltat.

Én az SVN becsekkolásnál írt kommentre gondoltam egyébiránt. Voltak gondok átmigrálásnál az ékezetes kommentekkel, de erről a doksi mélyen hallgatott - gondolom akkor ez bug.

[ Szerkesztve ]

Van e valakinek ötlete erre?

Egyetlen egy LibreOffice Calc fájlunk van, ahol nagyon fontos, hogy régi, lokális verzióval ne tudjuk felülírni a szerveren tároltat. Hogyan lehet ezt megoldani?

https://www.coreinfinity.tech

Tedd írásvédetté.
Ha SVN-t használtok és a véletlen felülírásoktól akarod megvédeni, akkor állítsd be a needs-lock attribútumot, véletlenül senki sem fogja lockolni.

DRM is theft

Nem voltam elég világos.

Szóval: a dokumentumot időnként update-elni kell Windows-os és/vagy Linuxos számítógépekről. Azt akarom elkerülni, hogy valaki megnyitja, update-eli és elmenti, de közben még valaki megnyitja az előbbi mentés előtt, majd az előbbi mentés után ráment. Ilyenkor az első update elveszik és csak a második lesz meg, holott mindkettő kellene.

https://www.coreinfinity.tech

Erre jó a lock. Valaki kiveszi és más addig nem tudja. Ha ő befejezte, akkor lehet másnak is kivenni. De ilyet nem csak SVN-ben lehet, simán oprendszerben egy távoli megosztott doksinál is működik, hogy aki megnyitja szerkesztésre, annál van, a többieknek addig csak read only.

És valami verziókövető rendszerben van, vagy csak úgy kirakva valami share-re?

DRM is theft

Nincs verziókövetés, egy fájl miatt ágyúval verébre szitu lenne. Share nincs, egy Ubuntus gépen van ez a fájl. Sambával lehetne valamit kezdeni?

stevve: ha megosztom, akkor ez működik?

[ Szerkesztve ]

https://www.coreinfinity.tech