Új hozzászólás Aktív témák
-
nagyúr
válasz Aethelstone #8950 üzenetére
> Nem érzem, hogy releváns különbségek lennének a két rendszer (svn, git) között.
Hat de tokre vannak, mert akar vonaton ulve, nethozzaferes nelkul is tudok commitolni giten. A nemzetkozi projekt meg a full remote work az mas
[ Szerkesztve ]
while (!sleep) sheep++;
-
Cathfaern
nagyúr
Ezt az Git-es local repo dolgot én se tudtam megértetni az egyik fejlesztőcsapattal ahol be akartuk vezetni. Mert mindig jött, hogy de olyan nincs, hogy egy fejlesztő úgy dolgozik, hogy az nincs fent a szerveren. A dologban csak az volt a vicces, hogy ezt pont az a fejlesztési vezető mondogatta a leghangosabban akinek már veszett el 1,5 heti munkája amiatt, mert nem commitolt svn-en... (és ennek ellenére is továbbra is notórius 2-3-4 naponta commitelő volt)
-
Aethelstone
addikt
válasz Cathfaern #8953 üzenetére
Nos, az ilyeneknek meg sültkolbásszal verném a kezét addig, amíg rá nem szokik a gyakoribb commitra Ugyanis ahogy írod is, a commit(push) nem csak azért van, hogy mindenki lássa, amit műveltél, hanem egyfajta biztonsági másolat is. Ha pedig csak a lokális repóba tolod bele, akkor olyan, mintha semmit nem csináltál volna biztonsági másolatilag.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
nagyúr
válasz Aethelstone #8954 üzenetére
> A GIT-nél beletolod a lokális repódba, ami kb. ugyanaz, mintha nem tolod fel hálózati kapcsolat hiányában SVN-be.
Hat de rohadtul nem, mert van history, van rollback, vannak branch-eid -- helyben. Kevered a biztonsagi masolatot a commit historyval kicsit.
[ Szerkesztve ]
while (!sleep) sheep++;
-
Aethelstone
addikt
Nem éreztem még annak szükségét, hogy lokálisan legyenek ilyen dolgaim. Ergó, ismét oda lyukadunk ki, hogy feladatfüggő, hogy mit használ az ember, nincsenek abszolút jó vagy kevésbé jó eszközök.
Szerk: Másrészről SVN-el is lehet local repót csinálni, amit szinkronizálhatsz a remote repóval.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz Aethelstone #8955 üzenetére
+1 a sült kolbászra
Ezt a lokális repository-t nem vágom SVNnél sem amúgy, kb arra jó, hogy megtanulja az ember. Vagy hogy a klasszikust idézzem némi módosítással: "Aki szerint ez version control, tegye fel a kezét, tegye fel a kezét, tegye fel a kezét..."
-
Aethelstone
addikt
-
nagyúr
válasz Aethelstone #8959 üzenetére
> Olyat sem, aki a GIT-nél nem a commit/push-t használta, hanem csak a commit-ot
Ez nagyon fura, en folyamatosan commitolok. Aztan idonkent meg fetch -> merge -> push.
while (!sleep) sheep++;
-
Lortech
addikt
válasz Aethelstone #8959 üzenetére
Azért nem kell szándékosan félreérteni. Nálam simán előfordul, hogy egy adott branchre csak commitolok és remote-ba sosem jut el ( csak a commitok, de azok már másik branchen, vagy a commitok sem).
Sőt egyébként olyan dolgokra is használom a git-et, amiknél nincs is remote, csak az a lényeg, hogy verziókat vissza tudjam követni. Pl. saját doksik, lokális fejlesztői környezetek bizonyos részei, toolok, konfigok verziózása. Bár ez is megoldható svn-nel, csak nem áll már kézre.Thank you to god for making me an atheist
-
floatr
veterán
válasz Aethelstone #8964 üzenetére
Engem csak az bosszant, hogy számtalanszor hallom puffogtatni, hogy aki SVN-t használ az inkább húzza le magát, mert a GIT istencsászár úgy általában, de értékelhető érveket nem nagyon látni. Amikor meg próbálom tisztázni, hogy mi az az aduász érv, ami ennyire nyilvánvalóvá teszi, hogy az SVN-nek vesznie kell, és GIT még a kenyérpirítóra is, akkor teljes kakukk. Az eddigi egyetlen értékelhető érv az volt most, hogy vonaton utazik és mobilnet. Gondolom nem ez teszi ki az idő nagy részét, de ok. Van már egy speciális eset, amikor esetleg van értelme a hype mellett.
Kicsit ugyanez az összes többi hasonló vita, amikor igazán érvek nem működnek, mert nem is nagyon vannak. Nem hallottam pl. a gradle mellett, hogy hierarchikus build, pedig elvileg mi el vagyunk tájolva az emlékek erdejében.
-
nagyúr
Dehat ott vannak az ervek lent, csak az a valasz, hogy 'az ugy nem jo'. Az, hogy minden szarra tudsz pillanatok alatt eldobhato branchet csinalni, az peldaul erv. Erre mondhatod, hogy szerinted nem ertelmes, de a gyakorlat meg azt mutatja, hogy igen, az.
while (!sleep) sheep++;
-
MODERÁTOR
Az a baj, hogy alapból két különböző dolog lett összehasonlítva. Szerintem sem rossz az SVN de ha tehetem Gitet használok. Ez nem bűn, hiba stb. egyszerűen jobban kézreáll.
Ez olyan mint melyik a legjobb PHP keretrendszer. Mindenki a Laravelt nyomatja, mert menő, holott sokkal jobb mint néhány konkurens. De ez sem volt jó példa.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
válasz Aethelstone #8968 üzenetére
Iszom inkabb egy jo sort. Gyertek ti is hozzank sorozni. [link]
while (!sleep) sheep++;
-
Lortech
addikt
Ok, ha megfordítod, SVN mellett mi szól? Egyet tudok mondani, az egyszerűséget, ami abból fakad, hogy nem dvcs. Talán még a részleges checkout, ha valakinek ez szempont.
A git szerintem a legtöbb dolgot jobban tudja, flexibilisebb, rengeteg parancs van, végtelenségig paraméterezhető, gyors, hatékony, mindenre ráhúzható. Komplex problémákat lehet vele megoldani viszonylag egyszerűen. Egyszerűen git > svn.
A szakma SVN-nel szemben ezt preferálja egy ideje, legalább is az a rélsze, amivel én találkozom. Enterprise nyilván lassabban mozdul. Open source közösség egyre inkább ezt preferálja, github kb. megkerülhetetlen manapság, ha kimaradsz, lemaradsz - az eredeti kérdés szempontjából ezt tartom lényegesnek.
Konkrét előnyét is éreztem mostanság az elosztottságnak, normálisan tudtam dolgozni olyan ügyfélnek, akinek a repójához VPN kell (ez a VPN elég trükkös, és igencsak megnehezíti az életet, ha megy). Házon belül több fejlesztővel (folyamatos) VPN elérés nélkül tudtunk dolgozni, egymásnak reviewzni a saját workflownkban, saját eszköztámogatással az ügyfél dolgaitól teljesen függetlenítve magunkat, minden probléma nélkül, elegáns megoldással.
Egyébként most kéne presaleselnem egy svn > git átállást ügyfélnek, az anyagot lehet, hogy megcsinálom, de simán nem erőltetem (nem támogatom), mivel kis, központosított csapatuk van, erőforráshiánnyal, és mást tartok magasabb prioritásúnak. Szóval azért nem vagyok git hívő, csak használom, és látom, hogy jó.
Arról meg szó sem volt, hogy húzza le magát valaki, mert SVN-t használ, eredeti felvetés az volt, hogy érdemes-e git-et tudni.
Én Gradle mellett nem érveltem, mert nem érzem szükségét, ős Mavenes vagyok amúgy. Még a hello worldöm is multimodule maven projekt.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Aethelstone
addikt
Akkor le van toszva az összes verziókezelő, irány sörözni
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz Lortech #8970 üzenetére
Az a probléma, hogy általában nem az a kérdés hangzik el, hogy "mit kezdjünk el használni: GIT vagy SVN?", hanem az, hogy "SVN-t használunk, mi indokolja, hogy GIT-re migráljunk?"
De elmondtam már az indokaimat. Emvy említett egy use case-t, amire jó a GIT. Nekem kicsit erőltetett, de szubjektív, kivéve persze ha az a jellemző munkafolyamata, hogy napi 10 órát utazik és közben fejleszt. Szerintem a projektek túlnyomó része nem elszigetelt fejlesztők részben merge-ölt munkájára épül, sőt... Ehhez képest a GIT csak feleslegesen komplikálja a munkádat, és ez a problémám, hogy nem észérv szól mellette, hanem az, hogy kimaradsz-lemaradsz, mertmindenkiezthasználja.
Nekem a legfájóbb pontja a GIT-nek ez az állandó disconnected feeling, mintha még mindig a dial-up korszakban lennénk. Bárhová megyek a laposommal az esetek 99%-ában, mindenhol legalább 100Mb-es netem van, ami még VPN-en is több mint elég. Semmi nem indokolja, hogy ne tegyem láthatóvá, és minden érintett számára elérhetővé egyből a munkámat. És nem elég az, hogy commit/push, de minden egyes alkalommal, amikor változást sejtek másoktól, még szinkronizálnom is kell külön, mintha nem is egy csapat lennél a kollégáiddal, ahol nem csak azért kell megszenvedned, hogy a te változtatásaid bekerüljenek, hanem külön kis bunkerben élne mindenki lekapcsolt nettel, és az is külön kihívás, hogy a mások változtatásai egyáltalán lejöjjenek hiba nélkül. Nekem ez nem előrelépés, sajnálom.
Mindegy leszállok a témáról, mert értelme nem sok van vitázni róla.
-
MODERÁTOR
Lenne egy szakmai kérdésem!
Lenne egy helper osztályom amiben van pár getter (van egy vendor objektum amit szintén tartalmaz, és ami betölt magának egy adatbázist és abból pakolnám ki az adatokat). Hogy tudnám a "best practice" szerint ezt az objektumot újrahasznosítani?
Setter, konstruktor vagy instance?
Remélem érthető volt!
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
disy68
aktív tag
Lehet csk nekem, de nem egészen egyértelmű. Ez a helper osztály nekem egy service-nek hangzik, aminek van egy vendor dependency-je. A service-nek ezt a dependency-t illene konstruktorban átadni, mivel a funkcionalitásához nélkülözhetetlen (azaz ne is jöjjön létre példány anélkül, hogy működne). Nem tudom milyen az architektúra, de ha Java EE, akkor van context. A service valószínűleg valami singleton bean, amit újra lehet hasznosítani (figyelemmel a szálkezelésre, ha szükséges). Maga a vendor object is egy bean lesz ebben az esetben, amit szintén át lehet adni bárminek, ami igényli.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
MODERÁTOR
Ahogy leírtad az igaz, csak ez nem EE. Egy konzolos alkalmazás. Tehát elindul a program, letölti ezt az adatbázist, ha sikerült és nem szál el akkor pedig kipakolja belőle az infót. Ezt a helpert szeretném shared módon elérni - mert több objektum is használná.
Szerk.: most kvázi ez a vendor objektum be van ágyazva a helperembe. Ez lehet így nem lesz jó.
Szerk.: köszi, igazad lesz. Konstruktor.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
válasz Aethelstone #8983 üzenetére
Én simán átallitottam a csapatot egy 5 éves repoval együtt.
while (!sleep) sheep++;
-
floatr
veterán
Egy kicsit több konkrétum nem ártana
(#8984) emvy mi is lenyomtuk egy 124000+ revision-ös repo migrálását ezernyi branchel az íze kedvéért, meg megteheti bárki, hogy dupla munkát csinál verziókezelés címen, de a kérdés sosem az, hogy meg lehet-e tenni.
Azt is megtehetné bárki, hogy megosztott verziókezelő filerendszeres könyvtárakba dolgozik, de minek. -
nagyúr
Mi azért tettük meg, mert az SVN kenyelmetlenne valt, ennyi. Nem volt egy nagy ugy, megkertem mindenkit, hogy pentek estig csekkoljon be mindent (vagy rakja el sajat maga valahova), szombaton konverzio, hetfon reggel kicsekkoltak az emberek gitbol. Aztan kb. 2 honapba telt, amig az oreg motorosok megertettek, hogy mi a merge meg a rebase kozott a kulonbseg, de megerte (szerintunk). 124e revizio mondjuk nem volt.
De oke, maradjunk abban, hogy preferencia kerdese. (Mint minden, olyan embert is lattam mar, aki szerint a nested for ciklusok tisztabbak, mint egy lambda )
[ Szerkesztve ]
while (!sleep) sheep++;
-
floatr
veterán
Elhiszem, hogy van olyan, akinek ez jobban bejön. Meg látom, hogy sokan ráizgultak a lambdára is, mert az megoldja minden problémájukat az életben
Nekem eddig a project lombok volt az egyik leghasznosabb(#8988) Cathfaern egy szavam se lenne, ha lenne egy olyan üzemmódja is, ami nem igényli a lokális repót. Bár csak ezért migrálni nem kezdenék akkor sem...
[ Szerkesztve ]
-
sutszi
veterán
Van lehetőség arra, hogy úgy parameterezzunk egy programot hogy a jvm azt másik mappába cachelje le?
Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage
-
floatr
veterán
válasz Aethelstone #8992 üzenetére
Inkább a hozzá kapcsolódó API, mert önmagában csak egy rövidítés. De részemről ok.
-
nagyúr
válasz Aethelstone #8992 üzenetére
Arra jo, hogy kicsit elgondolkozzanak az emberek arrol, hogyan is menedzselnek allapotot.
while (!sleep) sheep++;
-
MODERÁTOR
válasz Aethelstone #8996 üzenetére
Szerintem pedig musthave. Nem tudom miért kell mindentől félni.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
floatr
veterán
válasz Aethelstone #8996 üzenetére
Maradjunk annyiban, hogy nem rossz.
Most épp az egyik nagyobb megrendelőnket szeretnénk java6-ról upgrade-elni. Majd ha ezzel megvagyunk, és a projektet teleszórt lambdák miatt feleannyi melónk lesz, akkor aszondom h qvajó, bár akit kirakunk emiatt a projektről, az nem fog örülniDe most komolyan. A nyelvi eszköz nem sokat ér, ha nincsen hozzá ütőképes API. Ezt bebizonyította már nagyon sok eszköz a java ökoszisztémában. Sőt már minden rookie tudja, hogy az igazi értéke nem a nyelvnek van, hanem az ökoszisztémának. A 8-as API-k elég jóra sikerültek, bár ez is kissé kétélű, nem szabad mindenkinek a kezébe adni, mert ismerek olyan embereket, akik csak nagyobb bajt okoznának vele, mint nélküle. Persze képzés mindenekelőtt, de úgy látom mindenkinek vannak korlátai sajnos, de ez már csak a gyakorlati hasznosítás problémája, nem az elméleti öröm.
-
nagyúr
A nyelv meg a core libek meghatározzák a fejlesztők alapvető hozzáállását.
A lényeg szerintem, hogy 1-2 évente meg kell tanulni egy új nyelvet vagy valami új paradigmat, akkor is, ha nem használod a melóban, hogy tagitsa a latokort. Ha Springes vagy, nézd meg a Playt. Ha Javát látsz melóban, nézd meg a Clojure-t. Ha SQLt tolsz, próbálj ki egy kdb-t vagy valami graphql-es dolgot.
while (!sleep) sheep++;
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Házimozi belépő szinten
- BestBuy topik
- Gaming notebook topik
- Napelem
- Milyen processzort vegyek?
- Formula-1 humoros
- Elektromos rásegítésű kerékpárok
- Skoda, VW, Audi, Seat topik
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen