Új hozzászólás Aktív témák
-
Természetesen ez nincs kőbe vésve. Én nem alkalmazom és nem kérem másoktól sem, de ettől még jó sok kommentes kódot kapok - amikben a komment 90%-a teljesen felesleges, mert vagy olyat magyaráz meg, ami nyilvánvaló vagy olyat amit egy normális kódból kihámoztam volna egyedül is. (mielőtt felmerül, nem kis projektekről beszélek én sem)
Nem ítélem el, aki kommentet ír, csak én nem használom.
-
#63
whisperity
tag
julius666
#62
whisperity
tag
válasz
julius666
#62
üzenetére
Egyáltalán nem OFF
Az jó is lesz, mivel a képek verziókövetése/összefűzése (bináris mivoltuk miatt) igen csak körülményes. Tehát ha képeket kellett mergelni, akkor az kb. úgy zajlott le, hogy megnéztük hogy melyiket használjuk, és azt. Vagy beindítani a gimpet/ps-t és nekiállni összevágni.
-
cucka
addikt
A telekommentezett kód viszont lehet pont ugyanannyira érthetetlen, mint egy komment nélküli.
Figy, arra a problémára, hogy valaki rosszul kommentezi a kódját nem az a megoldás, hogy ne írjunk egyáltalán kommenteket.
Jelenleg én azzal foglalkozom, hogy egy számomra ismeretlen keretrendszerben írt, nagyrészt ismeretlen működésű rendszert kell fejlesztenem és nagyon hiányoznak a normális kommentek. -
#60
Blindmouse
senior tag
joghurt
#57
Blindmouse
senior tag
Namost vannak architechtúrák, amikre nincsen C++, C#, sőt még brainfuck fordító sem, ellenben 32 bites a szóhosszuk. Hála az égnek, így nem lesz az hogy jön egy magát programozónak hívó jáva kódoló (mert sajnos sok ember csak eddig jut el) és lefoglalja az egész memóriát 2 sorral, és miliszekundumokra a számolással. De ettől még nem szívesen gyártanánk fél megányi kódot ASM-ben. (btw az is C kód volt)
Nálunk Prog1-en azt mondta a tanár, nagyon helyessen:
"Aki nem tud angolul annak van egy hete megtanulnia a nyelvet"A knorr-nál is angol van.
-
A Siemens dolgot meg tudom erősíteni. Angol a belső nyelv.
Dev notes? Igazából csak nagyon speciális esetekben kell ezt is tölteni. Nem igazán jellemző a használata, de absz. belső anyag. Van hátránya, ezt elismerem. Például ha változik valami a kódban, követni kell a változást.
A telekommentezett kód viszont lehet pont ugyanannyira érthetetlen, mint egy komment nélküli. A felesleges komment meg ugye felesleges (például egy property nevét megmagyarázó szöveg, XML dokumentáció).
Ha a kódot magára hagyjuk és más nyúl hozzá később, aki még nem látta, szerintem egy kommentekkel dekorált verziót sem fog sokkal jobban megérteni. Azt meg nem a kódban kell tárolni szerintem, hogy egy adott fájl header része mit tartalmazhat. Ez nem fejlesztői tudás, hanem feladatspecifikus. Nem a kód része.
-
A Siemens belso nyelve az angol, az osszes hivatalos dokumentum, a kodban a kommentek* mind-mind angolul vannak. A nemet (finn, sved, akarmi) nagyon hasznos kiegeszito nyelv, de az angol tulajdonkeppen alapelvaras.
*: ill. a mult szazadbol imitt-amott biztos maradt meg nemi nemet szoveg
(#55) stevve: es a devnotesnak milyen elonyei vannak a kommenthez kepest? (mert hatranyt az igy elso blikkre is latok sokat)
-
#57
joghurt
addikt
Blindmouse
#52
joghurt
addikt
válasz
Blindmouse
#52
üzenetére
Akkor passzold át az angol-assembly fordítódat nekem, én is szívesen használnám!
A programozás nyelve mifelénk a C++, sebességkritikus helyeken az assembly, őskövületekben a Pascal, néhány új dologban a C#, weben a PHP.
Erről amúgy a német nyelvű képzésen résztvevők jutnak eszembe. (Rendes BME Villanykar, de x félévet Karlsruhéban végeztek el - ennek megfelelően inkább felső- mint középfokú némettudással rendelkeznek, angollal nem feltétlenül.) Amikor az egyik előadó - hozzád hasonló szemlélettel - valami anyagot csak angolul osztott szét, valaki megkérdezte:
- De tanár úr! És aki nem tud angolul? Az forduljon fel?
Mire a tanár elgondolkodva felelt:
- Igen, az forduljon fel!Szóval ha pl. az itthon programozókat foglalkoztató egyik legnagyobb multihoz, a Siemens valamelyik leányvállalatához kerülsz (de lehet a szintén német Knorr-Bremse is), az angollal kitörölheted, és kizárólag németül leszel kénytelen kommentet írni/olvasni.
-
A Librét nem ismerem, de pl.: Excelnél alapból így működik. Ha valamit megosztok, akkor az első, aki megnyitja, az lockolja is, az alkalmazás lekezeli. Amíg ő fogja, a többieknek csak olvasható.
(#54) dabadab:
Értem. Ez valóban felvet némi igényt a kommentelésre, de én tipikusan ilyenekre (főleg az 1. pont) vezettem be a developer notes megoldást (lehet linkeket beszúrni, a trükkös megoldásokat leírni, magyarázatokat adni dolgokra pár sorban). Ha nagyon szigorúan vesszük, ez is komment, csak külső fájlban. -
Úgy tűnik, hogy igazán a problémát sem sikerült érzékeltetnem
Nézzük a következő (valós, bár kommentjeitől megfosztott) kódrészletet (konkrétan 7z file-ok headerét értelmezi, szerintem elég egyértelmű, hogy mit csinál, esetünkben a "case 2" rész az érdekes):current_base_stream = 0;
folder = 0;
substream = 0;
for ( file = 0 ; file < m_files_info.GetCount() ; file++ ) {
m_files_info[file].base_stream = current_base_stream;
substream++;
if ( substream >= m_main_stream.folders[folder].num_substreams ) {
substream=0;
switch ( m_main_stream.folders[folder].coders.GetCount()) {
case 1:
current_base_stream += 1;
break;
case 2:
current_base_stream += 1;
break;
case 4:
current_base_stream += 4;
break;
default:
return false;
break;
}
folder++;
}
}Ha megkapnád ezt a kódot, hogy "nesze fiam, tartsd karban", akkor:
1. Mennyire gyorsítaná meg a folyamatot, ha az elejére lenne írva egy kis szösszenet arról, hogy a 7z formátumban mit jelentenek a folderek, a substreamek meg a coderek?
2. Ha találsz egy olyan file-t, ahol a case 2-nél neked +=2 kell, akkor mi alapján döntöd el, hogy a += 1 az valami más esetet kezel (és ha igen, akkor mit?) vagy csak elírás (erre gondoltam a "feature v bug" címszó alatt)? Mi lenne erre a leghatékonyabb módszer?
-
#52
Blindmouse
senior tag
stevve
#42
Blindmouse
senior tag
Nem ugyanabban a hajóban evezünk. Ami programokat írok az inkább így szokott kinézni, és ez csak egy egyszerű értékadás lesz:
SPI2BRG=4;
Komolyan, döntsd el, komment nélkül hogy ez mit csinál.
Hogy ne maradjatok buták:
// Set the SPI2 clock to 8Mhznem csak x86-ra .netben írnak programokat az emberek, és lehet hogy más alkalmazásban elkell a komment.
joghurt: A programozás nyelve angol.
-
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.
-
sh4d0w
félisten
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.
-
Vagy ha a program moduláris és a lazán csatolás is fennáll. Engem igazán nem érdekel egy másik modul, de ha belenézek, azért el tudok igazodni rajta - mert elvben egy cég = egy konvenció. Nyilván 3 betűs rövidítésekkel elnevezve valamit nem lehet olvashatóvá tenni egy kódot és olyan nevekkel sem, amik egyáltalán nem utalnak arra, amit csinálnak.
Amikor valami nagyon speckó dolog van vagy meg kell jegyezni valamit, arra van a dev notes. Emiatt nem kell a kódot összepiszkítani. tudom, hogy az MS-nél a komment konvenció, de nem csak kis projekteknél, csapatoknál működhet. Sikerrel lehet nemzetközi projektekben is alkalmazni, ha egyről beszél mindenki. Ehhez pedig nem a kódban kell kommunikálni, hanem azon kívül.
egy jól megírt kódot x év után is elő lehet venni. Persze kell átállási, belelátási idő, de láttam már olyan kommentezett kódot, amit a komment ellenére sem értettem meg elsőre. Mondjuk ez már a másik véglet.
A bug vagy feature kérdés szerintem nem a kódba való... miért írnék ilyet kódba?
A mit kellene csinálnia kérdésre van unit test, funkcionális követelmények. A kódból annak kell kiderülnie, hogy mit csinál, nem annak,hogy mit kellene - mert akkor nem azt csinálja. -
"Egészen konkrétan egy C# kódot nem érdemes kommentezni, mert azt meg lehet úgy írni, hogy olvasható legyen."
Ez csak nagyon kicsike cegek es nagyon kicsi projektek eseten mukodik, ugyanis eleve ott van az, hogy par sor kommentet joval gyorsabb elolvasni, mint nehany tiz/szazezer sor kodot.
Aztan a kodbol lehet, hogy kiderul, hogy most mit csinal (vagy nem, mert ahhoz ismerni kellene azt is, hogy milyen inputot kap), az viszont nem, hogy miert csinalja, mit kellene csinalnia (v.o.: "ez most bug vagy feature?"), mi az, ami a mukodeseben stabil es mi az, ami valtozhat, stb. Egy "x += 1" sorhoz is tartozhat am sok-sok karakternyi komment, amiben veletlenul sem arrol van szo, hogy "most megnoveltuk x-et" (ahogy azt az altalad idezett elrettento pelda teszi).Szoval a nemkommenteles igazan csak akkor opcio, ha a projekten vagy csak egyedul dolgozol, vagy max egy-ket masik emberrel, akik szinten alaposan tudjak, hogy mirol van szo es nem kell majd x ev utan elovenni valami regi kodot hibajavitani, ahol mar te sem emlekszel pontosan minden reszletre es tulajdonkeppen csak trivialis dolgok vannak a kodban. Nekem ilyen munkahelyem meg nem volt
-
Egészen konkrétan egy C# kódot nem érdemes kommentezni, mert azt meg lehet úgy írni, hogy olvasható legyen. Egy java kódot vagy például egy D3D motort azért másként kezelnék. Nem a nyelv miatt, a feladat miatt. Így megfelelő a válasz?
Miért ne hagynák rám? Aki érti, tud olvasni a kódban, aki meg nem (projektvezető), annak mindegy. Persze ennek elég erős feltétele, hogy normális legyen az a kód.
Példa:
Ha ez nem egy oktatóanyag, mennyi értelme van a kommentnek? Szerintem semmi.// This block of code will add 2 numbers and then put
// the result in the memory
int memory = 2 + 5; -
Teljesen vilagos volt (legalabbis nekem) az, hogy checkin kommentekrol van szo.
A "kodot nem kommentelem" kijelenteseddel meg nem tudok mit kezdeni - ugyanis mar azt is nehezemre esik elkepzelni, hogy komolyan gondoljon ilyet barki, aki mar tenyleseges dolgozott, az meg, hogy ezt ra is hagyjak... -
#40
stevve
veterán
Blindmouse
#37
válasz
Blindmouse
#37
üzenetére
É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.
-
"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.
-
#38
joghurt
addikt
Blindmouse
#37
joghurt
addikt
válasz
Blindmouse
#37
üzenetére
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.
-
#37
Blindmouse
senior tag
stevve
#34
Blindmouse
senior tag
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.
-
"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.
-
"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"
-
#34
stevve
veterán
Blindmouse
#33
válasz
Blindmouse
#33
üzenetére
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.
-
#33
Blindmouse
senior tag
stevve
#24
Blindmouse
senior tag
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.
-
joghurt
addikt
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.
-
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.
-
tobal
tag
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. -
É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.
-
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. -
#19
Blindmouse
senior tag
Blindmouse
senior tag
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.
-
#18
Blindmouse
senior tag
whisperity
#15
Blindmouse
senior tag
válasz
whisperity
#15
üzenetére
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. -
Yany
addikt
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.
-
#16
cucka
addikt
Blindmouse
#14
cucka
addikt
válasz
Blindmouse
#14
üzenetére
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.
-
#15
whisperity
tag
Blindmouse
#11
whisperity
tag
válasz
Blindmouse
#11
üzenetére
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.
-
cucka
addikt
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.
-
#11
Blindmouse
senior tag
Blindmouse
senior tag
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.
-
ClayMore
aktív tag
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 
-
Wyll
őstag
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.
Tedd írásvédetté.
Nyilván megoldható, nem azt írtam, hogy nem. 
Mióta van az angolban ékezetes karakter?
Új hozzászólás Aktív témák
- Gamer PC-Számítógép! Csere-Beszámítás! I5 12400F / RTX 3070 8GB / 32GB DDR4 / 1TB SSD
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Eladó szép állapotban levő Samsung Galaxy A22 5G 4/128GB fekete / 12 hónap jótállás
- HIBÁTLAN iPhone 16 Pro 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3066, 100% Akksi
- LG 27GS60QC-B - 27" Ívelt - 2560x1440 - 180Hz 1ms - AMD FreeSync - Bontatlan - 2 Év Gyári Garancia
Állásajánlatok
Cég: FOTC
Város: Budapest