Új hozzászólás Aktív témák
-
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.
-
#8998
floatr
veterán
Aethelstone
#8996
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ülni
De 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.
-
#8997
mobal
nagyúr
Aethelstone
#8996
válasz
Aethelstone
#8996
üzenetére
Szerintem pedig musthave. Nem tudom miért kell mindentől félni.
-
#8994
emvy
félisten
Aethelstone
#8992
válasz
Aethelstone
#8992
üzenetére
Arra jo, hogy kicsit elgondolkozzanak az emberek arrol, hogyan is menedzselnek allapotot.
-
#8993
floatr
veterán
Aethelstone
#8992
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.
-
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...
-
-
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
) -
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. -
#8984
emvy
félisten
Aethelstone
#8983
válasz
Aethelstone
#8983
üzenetére
Én simán átallitottam a csapatot egy 5 éves repoval együtt.
-
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.
-
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.
-
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,
-
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.
-
#8974
Aethelstone
addikt
Aethelstone
addikt
Akkor le van toszva az összes verziókezelő, irány sörözni
-
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. -
#8969
emvy
félisten
Aethelstone
#8968
válasz
Aethelstone
#8968
üzenetére
Iszom inkabb egy jo sort. Gyertek ti is hozzank sorozni. [link]
-
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.
-
-
#8965
floatr
veterán
Aethelstone
#8964
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.
-
#8962
Lortech
addikt
Aethelstone
#8959
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. -
#8961
emvy
félisten
Aethelstone
#8959
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.
-
#8960
Aethelstone
addikt
WonderCSabo
#8939
Aethelstone
addikt
válasz
WonderCSabo
#8939
üzenetére
Csináljunk!
-
#8958
floatr
veterán
Aethelstone
#8955
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..."
-
#8957
Aethelstone
addikt
emvy
#8956
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.
-
#8956
emvy
félisten
Aethelstone
#8954
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.
-
#8955
Aethelstone
addikt
Cathfaern
#8953
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. -
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) -
#8952
emvy
félisten
Aethelstone
#8950
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
-
#8950
Aethelstone
addikt
emvy
#8947
Aethelstone
addikt
Nem érzem, hogy releváns különbségek lennének a két rendszer (svn, git) között. Én dolgoztam nemzetközi projektben SVN alapokon és 4-5 fős, helyi csapatban is GIT-tel. Mindkettő használható volt, oda kellett figyelni a hülyeségeikre és minden flottul ment. Minden másra ott a Mastercard
-
#8949
mobal
nagyúr
Aethelstone
#8946
válasz
Aethelstone
#8946
üzenetére
+1
-
floatr
veterán
Épp arra próbáltam rávilágítani, hogy nincsen olyan h nem "mások szeme előtt maszatolsz". Nem vagy kénytelen összevissza másolgatni, mert ha létezik olyan a projektben, ami vakvágány, kivezetett branch, akkor azt megfelelő archív helyre mozgatod a repoban. Aki gyors munka miatt marhaságot csinál, azon a GIT sem segít. Épp ezért mondom azt, hogy szvsz egy totális félreértés a GIT hypetrain, ami egy olyan forrásból indul ki, ami bizonyos körökben fel van magasztalva már-már hites meggyőződéssel, és ezért nézem rossz szemmel azt, amikor erről indítanak, mert többnyire (tisztelet a kivételnek persze) fogalmuk sincsen h miért, csak azt látják, hogy "mindenki GIT-et használ". Elég radikális vélemény, tudom, mert a hype-széllel szemben témázok.
-
#8947
emvy
félisten
Aethelstone
#8946
válasz
Aethelstone
#8946
üzenetére
Nalunk eleg kritikus pont, mert ugye nincs iroda, 100% remote az egesz ceg.
-
#8946
Aethelstone
addikt
Aethelstone
addikt
Egy szónak is száz a vége, mindenki azt használ, amit
1. akar
2. lehetősége van rá (céges policy pl.)Nagyon szép világ lenne, hogy ha az lenne a legnagyobb problémánk, milyen verziókezelőt használjunk
Ugyanez igaz az Ant/Maven/Gradle/mittomén témakörre is. Ez benne a szép, hogy nem vagyunk Visual Studiohoz kötve
-
> a GIT egy eszközt ad a kezedbe arra, hogy személyes maszatolást csinálj anélkül, hogy nyoma legyen
Arra ad eszkozt, hogy ha epp maszatolni vagy kenytelen, akkor azt ne masok szeme elott csinald. Ertsd: elkezdesz valamit, es fel nap utan rajossz, hogy total rossz irany. Vagy csak valamivel kiserletezel, bejon egy gyors bugreport, amit fixalni kell -- SVN-hasznalok altalaban ilyenkor azt csinaljak, hogy lemasoljak a kiserletuket egy masik konyvtarba :\
En ugy latom, hogy aki SVN-t hasznal uj projekt eseteben, az elsosorban azert teszi, mert nem erti vagy nem probalta meg a modern VCS-eket (tokmindegy, hogy git, hg, vagy mas). Ez eleg radikalis velemeny, tudom.
(es nem szemelyes, egyaltalan) -
floatr
veterán
Nekem meg nem irreleváns, mivel a GIT egy eszközt ad a kezedbe arra, hogy személyes maszatolást csinálj anélkül, hogy nyoma legyen. Local history gyakorlatilag a nullával egyenértékű, ha meg mindent betolsz két lépésben, akkor meg csak feleslegesen bontottad ketté a GIT révén a folyamatot. Mindegy, nem akartam nagyon vitába keveredni, de én csak a divatot látom ebben az egészben az esetek 90%ában.
-
Lortech
addikt
SVN-nel ugyanúgy lehet olyan munkád, aminek nincs nyoma a központi repóban (egyszerűen nem tolod fel, ha nem akarod), a GIT viszont segít abban, hogy ha ezt akarod, kényelmesen meg tudd oldani, akár központi repóhoz fordulás nélkül, de úgy, hogy commitok (vagy stashben a változások) meglegyenek.
Nálam van, hogy 5+ feature branch között váltogatok napon belül, ha segítek vagy reviewzok kollégáknak. Eközben a saját munkám 1-2..n branchen van, amiket vagy feltoltam a remote-ba vagy nem, nincs jelentőségük, lényeg, hogy az infó megvan, és könnyen tudok váltani köztük. Van egy csomó olyan köztes állapota az elvégzendő munkának, aminek vcs historyban nincs különösebb keresnivalója, mert a végeredmény szempontjából nem hordoz értéket, mégis a köztes állapotnak is meg kell lennie, hogy később vissza tudjak rá váltani, ha folytatom a munkát rajta. Ugyanakkor más számára nem mindig hordoz értéket és így teljesen felesleges a feltöltésével időt vesztenem. A kész feature / javítás / akármi pedig úgy fog visszakerülni a masterbe / egyéb protected branchbe, hogy az csak azokat a commitokat és olyan üzenetekkel tartalmazza, ami a módosítás egésze szempontjából lényeges, és a historyban megőrzendő információ.
Ez nem azt jelenti, hogy nálunk a kollégák 2 hétig a saját kis játszóterükben szórakozhatnak, és ha elüti őket az autó, akkor annyi a munkának. Már csak a CI miatt is sokkal rövidebb életciklusú (vagy folyamatos integráció) branchek szükségesek. Erről git-nél és SVN-nél is le lehet szoktatni őket, ebből a szempontból én nem látok nagy különbséget. Pl. ha látom, hogy kolléga egyik remote branchre sem commitolt egy hete (van róla stat), akkor azért megkérdem, hogy mi a hasfájása. -
> Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban.
Ez irrelevans, mert a localhoston SVN eseteben is lehet olyan munka, aminek nincs nyoma a ceges repoban. SVN eseteben sem koveted az osszes fajlrendszerbeli valtozast. Szoval egyszeruen felreerted ezt a dolgot.
-
#8939
WonderCSabo
félisten
Aethelstone
#8937
WonderCSabo
félisten
válasz
Aethelstone
#8937
üzenetére
Kene egy SCM topik. Vagy mar van?
-
floatr
veterán
Első körben tisztázzuk, hogy céges környezetben, céges fejlesztési policy-val nézem ezt az egészet. Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban. A branch létrehozása egy mozdulat, ha a céges projekteken bíbelődsz valamit, az nem saját kis mitymuty, tessék létrehozni egy branchet akár kísérleti jelleggel a központi repóban, egy hosting/rendszergazda/devops kollégának meg legyen az a dolga, hogy ennek a feltételeit megteremti.
Minden branch minőségbiztosítási okok miatt meg kell hogy legyen központilag, lefedve egy task management rendszerrel úgy, hogy bármikor bárki tudja folytatni, review-olni, vagy épp merge-ölni DEV/UAT/PROD környezetbe.
#8933) WonderCSabo a másolás egy logikai művelet. Ellentétben néhány más rendszerrel, SVN alatt nincsen olyan speciális művelet, hogy branch, mivel nincsen erős kötöttség arra vonatkozóan, hogy a repoban mit hova teszel. Branch-et úgy csinál, hogy egy másik branch (URL) adott állapotáról egy referenciát készít az új URL-en. Meg kell határoznod a saját workflow-dat, hogy milyen elnevezéseket és kötöttségeket használsz. Ez nyilván lehet az eredeti ajánlás szerinti is, bár az csak egy viszonylag egyszerű munkafolyamatra jó.
(#8937) Aethelstone rebase
-
#8937
Aethelstone
addikt
WonderCSabo
#8935
Aethelstone
addikt
válasz
WonderCSabo
#8935
üzenetére
A merge GIT esetében sem valami leányálom, hiszen a problémát sosem az okozza, ami simán megy, hanem az, amit kézzel kell basztatni. Ehhez meg már semmi köze a verziókezelőnek. Nekem spec. a GIT-es push/pull/commit szarakodás tudja kiverni a biztosítékot, de ez is nyilván ízlés és gyakorlat dolga. Ahogy a kolléga korábban írta, a GIT inkább a sejtszerűen elhelyezkedő fejlesztői csoportoknak kiváló, ahol mondjuk nincs állandó kapcsolat a központi repóval, mert vpn, stb. kell hozzá.
-
#8936
Sirpi
senior tag
Chesterfield
#8929
Sirpi
senior tag
válasz
Chesterfield
#8929
üzenetére
A parseInt nem kezeli a belső szóközöket.
-
#8935
WonderCSabo
félisten
Aethelstone
#8934
WonderCSabo
félisten
válasz
Aethelstone
#8934
üzenetére
Valoban, ezt en is most olvastam el. Ugy emlekeztem tok szopas volt a branching, lehet ez mar nem igy van... Mindenesetre a szerver komm miatt megis lassabb lesz.
A merge-el viszont nagyon sokat szivtunk anno, de most olvasom az is fejlodott SVN-ben az evek soran. -
#8934
Aethelstone
addikt
WonderCSabo
#8933
Aethelstone
addikt
válasz
WonderCSabo
#8933
üzenetére
Részlet az SVN doksiból:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html
"Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. "
-
#8931
floatr
veterán
WonderCSabo
#8928
floatr
veterán
válasz
WonderCSabo
#8928
üzenetére
Nem történik másolás
Ha neked másolás történt, amikor SVN alatt brancheltél, akkor valamit nem jól csináltál.Én pont emiatt akadtam össze egy indiai fejlesztőcsapattal, mert korábban nem használtak VCS-t, de az SVN túl sok volt nekik. Minden egyes branch, amit létrehoztak, előzmény nélküli volt, egy teljesen új artifact, korábbi entitásoktól relációmentesen. Azóta is csak tippelek, hogy mi a bánatot csináltak rosszul.
Egy dolog van, ami sebességbeli probléma lehet. Az SVN közvetlenül a központi repository-ban dolgozik, ott hozza létre a bejegyzéseket. Ez ha rosszul van méretezve, lassú is lehet, értsd itt lassú alatt azt, hogy 2-5 másodperc. GIT esetében a saját gépeden lévő repositoryban hozod létre a branchet, amit csak te használsz, nyilván nincsen érdemi hálózati bottleneck, és más júzerekkel sem kell küzdenek a processzidőért. Ellenben ha feltolod a központi repóba, akkor megcsinálja ugyanazt, amit az SVN (nem másolás). Lehet hogy ez gyorsabb valamilyen oknál fogva a GIT esetében (nem 5 másodperc, hanem 2), de erős túlzásnak érzem azt, hogy ez a 2 vs 5 másodperc valakinek probléma.
(#8930) fordfairlane ha valamit elk.tál, akkor elég nehéz tud lenni. De akkor GIT branch/mergenél meg a push a kellemetlen
-
#8930
fordfairlane
veterán
WonderCSabo
#8928
fordfairlane
veterán
válasz
WonderCSabo
#8928
üzenetére
Nem a brancs a nehéz SVN-ben, hanem a merdzs.
-
#8929
Chesterfield
őstag
Chesterfield
őstag
Itt vajon miért kapom swingben a következő hibaüzenetet?
Exception in thread "AWT-EventQueue-0" java.lang.NumberFormatException: For input string: "1 0000"
private void bt0ActionPerformed(java.awt.event.ActionEvent evt) {
if (kiiras.getText().length() < 20) {
String outPut=kiiras.getText() + "0";
outPut= outPut.replaceAll("\\s+", "");
outPut=String.format("%, d", Integer.parseInt(outPut));
kiiras.setText(outPut);
}
}Ez a "0" gomb lenne egy számológépben.
Valamiért mintha nem távolítaná el a space-eket a formázott kiírásból. -
#8928
WonderCSabo
félisten
floatr
#8927
WonderCSabo
félisten
En dolgoztam SVN-nel is, git-tel is, es az utobbira szavazok. Nem teljesen ertem hogy azt mondod "feature branchingre inkább való az SVN", mikozben az SVN-ben egy branchet eleg pain letrehezni (hiszen valojaban masolas tortenik), mikozben git-ben csak egy pointer allitodik at pillanatok alatt.
-
floatr
veterán
Szerintem feature branchingre inkább való az SVN. Az kétségtelen, hogy programozó sejtekbe csoportosulva a GIT jobban skálázódhat, de finoman szólva nem ez határozta meg a felhasználási területeket egyetlen projektnél sem -- legalábbis nálunk.
(#8924) Lortech Tisztában vagyok vele, hogy a gradle irányába folyik még a Duna is, de egyelőre általános felhasználásra kicsit még kísérleti szaga van. Kell neki még egy kis idő, de hiánypótló az ANT után.
A GIT meg nyilván felhasználás kérdése, ha kell, akkor kell. Én viszont a GIT-tel vagyok úgy, hogy az utóbbi években kialakított workflow-t csak megnehezítené. Nemrég írtam egy scriptet is SVNhez, hogy még azzal se kelljen időt pocsékolni, hogy kattintgat az ember a branchek között, meg a history-ban merge előtt, nem sokból tartana GIT-re átírni, de csak a változtatás kedvéért teljesen feleslegesnek érzem a változtatást. Én inkább érzem arculati tényezőnek, mint valóban hasznos eszköznek. Kicsit olyan érzésem van vele kapcsolatban, mint amikor az ember összekötött kézzel akar úszni, hogy más is láthassa, hogy tud összekötött kézzel is úszni.
-
"Akinek egy maven-féle XML szerkesztése gondot jelent, az válasszon más pályát
"Én ilyet nem mondtam, csak azt, hogy minek irogassak XML-t ha nem muszáj.
"és elég gyerekcipőben jár a támogatása az egyes IDE-kben."
Csak ismételni tudom magam. Idea, megnyitom mint gradle projekt és kész. Semmit nem állítok neki az ég világon.
Gitre, #8924.
-
Lortech
addikt
Gradle Android/studio-nál megkerülhetetlen.
Git akkor komplikáltabb, ha komplikáltabb dolgokra használod. Sokaknál azt veszem észre, hogy git előtt csak egyszerű dolgokra használta a vcs-t, git után ráérez és elkezdi jobban érdekelni a dolog.
Nagyon egyszerű felhúzni új repót, gyors, hatékony, jól skálázódik, jól testreszabható, tök jó támogató eszközök épültek köré, jól üzemeltethető.
Az SVN a jelenlegi workflowt, amit használunk, nehezen tudná jól támogatni, legalábbis az én munkámat dev leadként. Mondhatnám én is, hogy akinek gondot jelent pár nap alatt belerázódni a GIT-be, az válasszon más pályát. Sima alkalmazásfejlesztőknek kb. három mondatban le tudom írni adott projekten az össz teendőjét gittel. Kb. 6 éve az összes projektemen git mellett döntök, SVN-ről váltottam, azóta soha eszembe nem jutott SVN-t használni, ha nem adottság. Ha SVN-t, neadjisten CVS-t, vagy CC-t látok (ügyfélnél), hamar idegrángásom lesz tőle és általában felrakok fölé egy GIT-et.#8908 eredetire: igen, mind a 4-re szükséged van, de ha nem senior pozíció, akkor alap szinten ismerni elég ezeket. Komolyabban úgyis munka közben tudod megtanulni.
-
#8923
emvy
félisten
Aethelstone
#8917
válasz
Aethelstone
#8917
üzenetére
Minden feature vagy fix egy branch nalunk.
-
floatr
veterán
Re maven/gradle: a gradle megítélésem szerint még elég kiforratlan dolog, és elég gyerekcipőben jár a támogatása az egyes IDE-kben. Sajnos én addig nem tudom eléggé komolyan venni a dolgot. Mondom ezt úgy, hogy egy nagyobb projektcsomagot migrálunk most gradle-re. Akinek egy maven-féle XML szerkesztése gondot jelent, az válasszon más pályát
Re SVN/GIT: nagyon menő egy ideje a GIT, és mindenki migrál veszettül, ész nélkül sajnos. A legtöbb projekt ugyanis nem igényli a GIT modelljét, ellenben komplikáltabb a használata. Tapasztalatom szerint még az SVN használata is kihívás sokaknak, nemhogy a GIT. Biztos van helye a GIT-nek is (pl nagy projekt kis, 1-2 személyes, javarészt független alprojektekkel), bár én eddig még sehol nem láttam indokoltnak, leszámítva azt az esetet, amikor egy ügyfél előtt pozicionálunk arculatot.
-
#8920
Chesterfield
őstag
Chesterfield
őstag
köszi a válaszokat
-
#8919
Aethelstone
addikt
mobal
#8918
-
#8918
mobal
nagyúr
Aethelstone
#8917
válasz
Aethelstone
#8917
üzenetére
Ha kvázi egy szoftvert csinálsz 50 féle hardverre. Máshogy szerintem nem tudod megoldani jól.
-
#8916
mobal
nagyúr
Aethelstone
#8915
válasz
Aethelstone
#8915
üzenetére
Ezt szerintem projektje válogatja. Jelenlegi munkahelyemen van vagy 200 branch.
-
#8914
emvy
félisten
Aethelstone
#8912
válasz
Aethelstone
#8912
üzenetére
> A cégek jellemzően maven/svn kombót használnak
Azert az SVN nagyon nem skalazodik, ahogy en latom, a nagy cegek inkabb Perforce-rol mennek lassan git-re.
A Google-nal pl. sajat, Mercurial-ra epulo VCS van, mivel egyetlen repo van az egesz cegnel.
-
#8913
mobal
nagyúr
Aethelstone
#8912
válasz
Aethelstone
#8912
üzenetére
"hiába érkeznek az ifjú titánok gradle/git ismeretekkel".
Minek szekresszek xml-t ha nem muszáj? Miért kell ragaszkodni a mavenhez? Kevesebbet tud.
Az svn-ről meg nem tudok nyilatkozni. Az van ami van, ha nem akarnak váltani nem ha akarnak meg úgyis tudnak.
Szerk.: vállalati környezet persze egy kizáró ok, ezzel tisztában vagyok.
-
#8911
mobal
nagyúr
Chesterfield
#8908
válasz
Chesterfield
#8908
üzenetére
Maven helyett mondjuk én már a Gradle-t nyomatnám.
-
#8910
Aethelstone
addikt
Chesterfield
#8908
Aethelstone
addikt
válasz
Chesterfield
#8908
üzenetére
Git-re nem feltétlenül, SVN is nagyon sok helyen van. Nyilván nem hátrány az ismerete
-
#8909
ToMmY_hun
senior tag
Chesterfield
#8908
ToMmY_hun
senior tag
válasz
Chesterfield
#8908
üzenetére
Első kettőre és a harmadikra amúgy is, azok nem EE specifikus dolgok.A kérdésedre válaszolva pedig igen, ezekre vagy alternatívájukra szükség lesz.
-
#8908
Chesterfield
őstag
Chesterfield
őstag
Sziasztok!
Java SE ismeretek megszerzése után, ha EE irányba mennék tovább, szükségem van ezeknek az ismeretére?
- Maven
- Git,
- Spring alap
- JPAköszi
-
#8904
mobal
nagyúr
Aethelstone
#8903
válasz
Aethelstone
#8903
üzenetére
Ez is igaz, de nem tudom, hogy grafikában hány tizedesig illik használni a Pi.
-
#8902
tboy93
nagyúr
Aethelstone
#8900
válasz
Aethelstone
#8900
üzenetére
Orai peldakodbol kimasoltam azt a reszt, azota mar atirtam PI-re
Amit el szerettem vna erni, hogy a gombom random pontjai random szammal legyenek eltolva ugymond kifele-befele, hogy ne szabalyos gomb legyen. Ezaltal hasonlitana a feladatban meghatarozott "aszteroidara".
-
#8901
mobal
nagyúr
Aethelstone
#8900
válasz
Aethelstone
#8900
üzenetére
Lehet, de lehet neki csak ennyi tizedesig kell.
És jó a kávé? 
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Hobby elektronika
- Gyúrósok ide!
- Motorola Edge 30 Neo - wake up, Jr...
- Tőzsde és gazdaság
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- Fűnyíró topik
- Projektor topic
- Xbox Series X|S
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- Megjelent az Infinix Note 50x 5G
- További aktív témák...
- Bomba ár! Lenovo ThinkPad X260 - i5-6G I 8GB I 256GB SSD I 12,5" HD I HDMI I CAM I W10 I Gari!
- MacBook felvásárlás!! MacBook, MacBook Air, MacBook Pro
- BESZÁMÍTÁS! ASUS ROG STRIX Z390-E GAMING alaplap garanciával hibátlan működéssel
- MacBook felváráslás!! MacBook, MacBook Air, MacBook Pro
- Csere-Beszámítás! Olcsó Gamer laptop! MSI Cyborg 15 . I5 12450H / RTX 4050/ 16GB DDR5
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest