Grarpamp a FreeBSD projekt git-re váltásában látná a megoldást. Ahogy az lenni szokott, az ötletfelvetésnek lettek pártolói és ellenzői is. Az ellenzők közt volt olyan, aki azzal érvelt, hogy a FreeBSD projektnek van (SVN-ből exportált) publikus git tárolója, aki azt szeretné használni, használhatja. Valaki megjegyezte, hogy valóban van git repo, de azzal problémák vannak.
Volt aki szerint a git nem felelne meg a bejáratott munkafolyamatokhoz. Más szerint megfelelne. Volt, aki szerint a git órási visszalépés lenne. A szálban természetesen megjelentek a BSDL-zelóták is, akik szerint a git-tel licencbeli problémák vannak.
A szálból a vita mellett azért értelmes infók is kinyerhetők a FreeBSD fejlesztését szorosan nem követők számára. Például az, hogy ugyan létezik jelenleg még git, SVN és CVS repó is, de az igazi repó az SVN. A CVS az SVN-ből exportált, a git szintén. A CVS meg fog szűnni.
Továbbá, az üzemeltetők minden igyekezete ellenére csak az SVN tekinthető minden időpillanatban naprakésznek. Akárhogy is igyekeznek, a git és CVS repók naprakészen tartásával, az nem megy mindig, minden körülmények közt.
A szál itt kezdődik.
- A hozzászóláshoz be kell jelentkezni
- 4111 megtekintés
Hozzászólások
git es repo integritas egy mondatban? :D
troll level ez, semmi mas
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Mesélj! :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
egy git fsck --full parancs remlik valami teljesen trivialis utan (SIGINT pull kozben talan?)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Még az a jó, hogy NetBSD-ben, és meg semmilyen más projektben, például az SVN-ben nem voltak ordas hibák...
- A hozzászóláshoz be kell jelentkezni
*a wild git fanboy appears*
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
te már bizonyítottan troll vagy, nem érdekel mit írsz. Egyébként én személy szerint nem használom a git-tet, csak, mint felhasználó. Az általánosítás, meg az 1 hiba alapján minden szar, kicsit véresszájú megközelítése nem tetszett. Az ilyen véresszájú dolog a gyengék fegyvere. Hiányzik az ilyen dolgokból a stílus, ez a stílus a móriczi ösztönlény, és a kádári kisember fröcsögő gyűlölete, az jön csak le ebből. Ezért tart itt az ország.
- A hozzászóláshoz be kell jelentkezni
"nem érdekel mit írsz"
Ilyen, amikor nem erdekel?
- A hozzászóláshoz be kell jelentkezni
"Ezért tart itt az ország."
Ez feltétlen kellett bele és hitelessé tette az egész hozzászólásodat. Nem mintha anélkül lett volna bármi értelmes benne mondjuk.
- A hozzászóláshoz be kell jelentkezni
+2π
Ráadásul a Git GPL licences ezért ideológiai okokból is ellenjavallt a használata. :D
- A hozzászóláshoz be kell jelentkezni
plusz egy a kétpire
- A hozzászóláshoz be kell jelentkezni
Szerencsére van jgit, ami BSD licenszes. :)
- A hozzászóláshoz be kell jelentkezni
most git a "menő", majd jön valami új megint aztán minden faszagyerek szerint az lesz az über.
én még mindig svn-ezek, de nem igazán érzem hátrányát. persze legtöbbször max 30-50 emberrel dolgozom.
- A hozzászóláshoz be kell jelentkezni
Valojaban mit szerettel volna kozolni?
- A hozzászóláshoz be kell jelentkezni
Én ismerek olyan céget idehaza, ahol kb. 20 dolgoznak és CVS-t használnak még mindig. Igaz csak naponta egyszer commitolnak, a munkanap végén. Na és? Nem normálisak mindenhol vannak. :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Mondjuk a "nap végi commit" szerintem eleve nem normális SCM-től függetlenül. :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Persze, de az SCM nem backup.
- A hozzászóláshoz be kell jelentkezni
Dolgoztam én 100+ emberes cégnél (mondjuk kb. fele fejlesztő) és ők is CVS-eznek. Szánalom.
- A hozzászóláshoz be kell jelentkezni
A git nem csak menő. Megszállott Visual Studio C++-osként mondom: A git és a Mercurial a két legjobban használható verziókövető rendszer. Pl: van normális branch kezelés, a cherry-pick nélkül meg lassan embert ölnék. :)
--
http://naszta.hu
- A hozzászóláshoz be kell jelentkezni
Egy kis történelem arról, hogy Linus miért nem szereti a cherry picking-et: link.
:)
- A hozzászóláshoz be kell jelentkezni
Mondjuk én no commit-tal tolom és átnézem commit előtt. Persze nem is kernel méretű dolgokkal dolgozom.
--
http://naszta.hu
- A hozzászóláshoz be kell jelentkezni
Bár még sosem cherry pickeltem, de a kezdeti szkeptikusság után ("minek egy új, bonyolultabb verziókezelő, amikor az svn mindent tud" (ami amúgy teljesen ugyanaz a gondolatsor volt, amit a winampról vittem, amíg nem találkoztam a foobarral)) teljesen beleszerettem. Ez már egész úgy néz ki, ahogy egy verziókezelőnek ki kell néznie. Mondjuk lehet azért gondolok rá ilyen pozitívan, mert amúgy emellett kellett elkezdenem a ClearCase használatát is, és hát éles a kontraszt. Az IBM-nél miért nem tudnak szoftvert fejleszteni? Az egész Rationale úgy szar ahogy van.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ez most hogy jött ide?
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
szerintem a RAD egesz hasznalhato.
- A hozzászóláshoz be kell jelentkezni
Hát még egyetemen kellett használni valahova, és nekem a tetűlassú és az ostoba szavak ugranak be róla. Azt láttam, hogy jól össze lehet benne kattintgatni mindent, de egyéb előnyét nem nagyon.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
clearcase-t nem az ibm fejlesztette fyi
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Na de ha lett volna egy csepp eszük, nem vásárolják föl azt a rakás fost.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
igazabol azokkal nincs valami rendben, akik a 21szd-ban meg fizetnek is erte
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Ezt maximálisan aláírom, de azért érdekel, hogy a fájlonkénti verziókezelés vajon kinek jutott eszébe, hogy jó ötlet lesz.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
A szakmai részéhez nem is kívánok hozzászólni, mert vallási vita (ez meg oximoron), de úgy tudtam a BSD fejlesztés egyik alapköve a licensz. Na most ha a git licensze nem megfelelő, akkor egyértelmű a dolog (feltéve, hogy az Subversioné jobb).
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Az alaprendszerben levő dolgok licencén szoktak szűkölni. Az SVN tudtommal nincs az alaprendszerben. Ennyi erővel semmilyen nem BSDL-es szoftvert se használjanak.
Jelzem, a DragonFly projekt git-et használ és nem lett tőle problémájuk. A FreeBSD-t BSD-s körökben eddig is Free???BSD-nek hívták. Szóval ez nem hiszem, hogy érv akkora érv lenne.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Kérdés, hogy az a dolog, ami segíti a fejlesztést, de nem épül bele a termékbe, az hozzá tartozik-e a licenc-körkérdéshez? Emlékszünk még arra hogy mi vezetett a git kifejlesztéséhez?
- A hozzászóláshoz be kell jelentkezni
Én pontosan emlékszem rá, de beszélhetünk róla.
Larry McVoy és a BitMover Inc. visszavonta az ingyenesen használható BitKeeper-t és helyette egy megnyomorított nyílt forrású klienset tett elérhetővé:
http://hup.hu/node/8502
http://hup.hu/node/8347
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Apropo, mi lett ezzel a ceggel? A honlapjuk alapjan nem tul aktivak.
tompos
ui.: Es mi lett a fo-fo patent trollal? Arrol mar regota nem volt cikk, hehe.
- A hozzászóláshoz be kell jelentkezni
A mercurial miert nem merul fel soha sem mint svn alternativa? Mi git-et hasznalunk a cegnel es bar ketsegtelenul egy nagyon fejlet scm de mondjuk intuitivnak szerintem egy csoppet sem nevezheto. Valaki hasznalt mar mercurialt "ipari" kornyezetben es meg tudna mondani, hogy miert jo /nem jo?
- A hozzászóláshoz be kell jelentkezni
"A mercurial miert nem merul fel soha sem mint svn alternativa?"
Odáig jutottak, hogy az egyik okos szerint a Mercurial licence BSDL, a másik szerint LGP míg a harmadik szerint GPLv2.
http://marc.info/?l=freebsd-questions&m=135336052019813&w=2
http://marc.info/?l=freebsd-hackers&m=135336050819457&w=2
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hat ez tenyleg nehezen megallapithato dolog...
http://mercurial.selenic.com/about/
Amugy GPLv2
A subversion meg apache licences bar hogy az hogy aranylik a BSDL-hez azt nem tudom...
- A hozzászóláshoz be kell jelentkezni
A Chris Rees által említett BSDL-t én sehol sem láttam. Márpedig nekik csak az jó.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha már alternatíva, Veracity, szép nagy összehasonlító táblázattal: http://veracity-scm.com/
Ezt http://www.ericsink.com/vcbe/ meg lehetett ingyen rendelni nyomtatott formában, meg is tettem és ebben azt írja, hogy a Veracity az új király. Mondjuk ront a képen, hogy a fejlesztőknél dolgozik az író, így objektívnek nem nevezhető. De alternatíva. :-)
"Belépés díjtalan, kilépés bizonytalan."
- A hozzászóláshoz be kell jelentkezni
"új király", miközben se bisect, se rebase?
- A hozzászóláshoz be kell jelentkezni
Mondjuk a git rebase azert egy kicsit veszelyes jatekszer... Szoval azert nem biztos, hogy konnyeket hullajtanek...
- A hozzászóláshoz be kell jelentkezni
A konyhakés is veszélyes, mégis ott van szinte minden háztartásban. Oké, gyerek kezébe nem adjuk és kicsit jobban odafigyelünk, ha használjuk.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
En konnyet nem, de epelme pontokat biztosan hullatnek rebase nelkul.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Veszélyesnek akkor nevezném, ha valaki nem tudja használni, tökéletes volt a konyhakéses hasonlat.
- A hozzászóláshoz be kell jelentkezni
A konyhakes tenyleg tokeletes hasonlat. Jelentkezzen, aki meg nem vagta el egyszer sem a kezet. Amugy meg tenyleg hasznos tud lenni, ha az ember eltoltott mar par honapot git elott. Viszont itt kerdeznem meg, hogy biztos ugyan arrol beszelunk-e, mert en nem vagyok nagy Git guru. En a magam reszerol a rebase -i altal elerheto localis repozitory editalo funkciora gondoltam es nem arra, hogy mondjuk a pull kozben megerkezo commit-okat rebase-elem. Az utobbi nyilvan egy nagyon jo dolog. Ez elobbi meg nagyon elegans es konyhakes jellegu.
- A hozzászóláshoz be kell jelentkezni
Ha pullolsz, és az upstream frissült, de mondjuk a lokális master branch 1 vagy több committal előbbre jár, és a változtatásaidat felpakolja az új állapot tetejére, akkor az fast-forward (belül valószínűleg ugyanaz történik mint mikor rebase -kor pl. megcserélsz két commitot).
A rebase amúgy érdekes kérdés, mert "általában" azt jelenti, hogy a commitokat szabadon mozgathatod, viszont a git rebase alá több parancs is tartozik, pl. egy régebbi commit reword -je (ami ugye maga után vonja a gyerek commitok sha-újraszámolását is). Nem tudom, hogy más scm -eknél mi tartozik a rebase körébe, de gitnél egyértelműen tágabb a halmaz. Valószínűleg azért vontak egybe egy csokor parancsot a rebase alá, mert már egyébként is több tucat főparancs volt a githez.
- A hozzászóláshoz be kell jelentkezni
Igen, megvágtam már a kezem késsel. És? Megmostam, fertőtlenítettem, beragasztottam, aztán aprítottam tovább, mert az ebédnek csak el kell készülnie.
A rebase-nél még ennyit se kell csinálni, bármikor vissza lehet állni a rebase-t megelőző állapotra, elvégre ezért van a reflog.
Az informatika már csak ilyen veszélyes üzem. Jobbklikket nyomsz egy file-ra, aztán ott a "Törlés" a menüben, borzalom.
- A hozzászóláshoz be kell jelentkezni
A veracity egy fos, a konyv semmi masrol nem szol, csak arrol, hogy toljon valami kisebb szekeret a veracity ala.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Írtam, gyanús, hogy az író ott dolgozik. De szélesítettem a látókört. :-) Én személy szerint git-et használok, nekem bőven megfelel.
"Belépés díjtalan, kilépés bizonytalan."
- A hozzászóláshoz be kell jelentkezni
A doksi egy kalap fost sem ér, a gitben is minden commit immutable, maximum egyes műveletek hatására új commitok keletkeznek, a régiek pedig a felületes néző számára eltűnnek (nem).
Szerk.: de van ipad client! Óje!
- A hozzászóláshoz be kell jelentkezni
Neked nagyon kimostak az agyad ottan gittel. :)
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Én csak annyit mondtam hogy a doksi hazudik amikor azt állítja hogy a git commit mutable. :)
- A hozzászóláshoz be kell jelentkezni
Én azt nem értem, hogy az svn+hg / svn+git kombinációk miért nem elég jók az embereknek? Megmarad a központi repo, plussz aki akar, az játszik saját dvcs-el.
--
blog: en | hu
- A hozzászóláshoz be kell jelentkezni
Egyrészt lassú, másrészt meg minek akkor az SVN? Git-ben és Hg-ben is lehet központi repó, csak mellette megvannak a helyi másolatok is. Én amúgy toltam így, nehézkesnek tűnt.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Az SVN központi repó előnye az egyszerű revision számozás, ami jelentősen könnyebb a build-felelősöknek és/vagy az üzemeltetésnek (főleg ha több verzió is futhat a programból, és vissza kell tudni nézni valamit). Én az svn+hg kombinációt használtam, az elviselhető sebességű volt - mondjuk én nem csináltam ötpercenként brancheket...
--
blog: en | hu
- A hozzászóláshoz be kell jelentkezni
A git előnye ott jön nagyon elő, amikor több verziót kell egyszerre életben tartanod egy programból. Ilyenkor azt csinálod, hogy a main line (master) a fejlesztési ág, és a verziók branchek. Az egyes frissítések pedig cherry-pick-kel szépen, egyszerűen visszacsorognak a régi verziókra. Valjuk be egymás közt: a branch kezelés elég fájdalmas SVN-ben.
--
http://naszta.hu
- A hozzászóláshoz be kell jelentkezni
A branch-kezelés és a branchek közötti váltás tényleg fájdalmas, de ahogyan a hg/git is klónoz egy repo-t, úgy igazából az SVN repo-t is lehet klónozni, és hasonló hatékonyságot el lehet érni vele. Igazából mindig az a kérdés, hogy milyen workflowban szeretnél dolgozni, és van amikor az svn dolgozik alád jobban, van amikor a másik megközelítés. Én azért pártolom az svn+hg / svn+git kombót, mert ugyan egy kicsit tényleg bonyolultabb mint a homogén választások, de össze lehet úgy rakni, hogy ki tudod használni mindkét technológiának az előnyeit, és a hátrányok inkább tompulnak.
--
blog: en | hu
- A hozzászóláshoz be kell jelentkezni
de ahogyan a hg/git is klónoz egy repo-t, úgy igazából az SVN repo-t is lehet klónozni, és hasonló hatékonyságot el lehet érni vele.
Ahhoz, hogy több branch-em legyen, ahhoz nem kell klónozni a repot ha git-et használsz. Egyetlen tree-ben lehet akármennyi branch, egyszerre. És egy pillanat alatt tudsz váltani köztük. Hogyan lehet ezt a hatékonyságot elérni SVN-nel?
van amikor az svn dolgozik alád jobban, van amikor a másik megközelítés.
Konkrétan mi az a feladat, amire az SVN jobb?
hogy ki tudod használni mindkét technológiának az előnyeit
Mik az SVN előnyei?
- A hozzászóláshoz be kell jelentkezni
Azért van az SVN-nek is előnye, bár tény, hogy nem sok.
Pl. valamilyen okból nem akarok a fejlesztőknek teljes hozzáférést adni, akkor hasznos lehet, hogy tudtommal a letöltött anyagból nem lehet reprodukálni az eredeti repót, a letöltött anyag használatához szükség van az eredeti repóra. (Ez persze lehet, hogy nem így van, régen SVN-eztem és akkor sem túl sokat.)
A másik előnye, hogy ha a repository nagy, akkor nem kell a fejlesztőnek letölteni mindent, pl. olyan ágat, ami nem is érinti. Azért a Git-ben egy nagyobb repónál, míg minden commit lejön, el tud tartani egy ideig.
Plusz elméletileg több program támogatja a kezelését, IDE-k stb.
Mindent összevetve azért én sem használnék SVN-t már.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Az svn legnagyobb előnye, hogy egyszerű, mint a faék. Ez sokszor fontos, amolyan legnagyobb közös nevező.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
> A másik előnye, hogy ha a repository nagy, akkor nem kell a fejlesztőnek letölteni mindent
git clone --depth ebben lehet felmegoldas (pusholni nem lehet a shallow clonebol, pl). A GitHub lehet egy masik megoldas, mert githubon minden repo egyben SVN repo is:
$ svn checkout https://github.com/algernon/libmongo-client/branches/stable lmc-stable
> Azért a Git-ben egy nagyobb repónál, míg minden commit lejön, el tud tartani egy ideig.
Igen, de ezt csak egyszer kell eljatszani, es mivel a git repo eleg kompakt, egy full git checkout igen sok esetben elenyeszoen tart csak tobb ideig, mint egy svn checkout. Es gitnel meg az is meg lesz, hogy ha netan megis szuksege van az embernek egy masik branchre, akkor az rogton ott van keznel.
> Plusz elméletileg több program támogatja a kezelését, IDE-k stb.
Kb minden ami el es mozog, es tamogat SVN-t, az altalaban gitet is. A "nagyok" mind.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Engem nem kell meggyőznöd, mert már régóta Git-et használok és élvezem. :) Csak azokat az érveket hoztam fel, amelyekkel gyakran találkozok, ha valahol felmerül a git-re migrálás. :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Ertem en, en meg felhoztam a megoldasokat a mindig felmerulo, egyebkent nem letezo problemakra ;)
--
|8]
- A hozzászóláshoz be kell jelentkezni
Amúgy egy ideig használtam Bazaar-t is (sőt, azon kezdtem az elosztott verziókezelőkkel való ismerkedést) és egész kellemes. Egyszerűbb, mint a git és (szerintem) többet tud, mint az SVN.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
SVN eseten lehet csak mappat checkoutolni ezt git eseten nem lehet.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
- A hozzászóláshoz be kell jelentkezni
Persze, git esetén nem tudsz checkoutolni. Teljesen értelmetlen az összehasonlítás. Ha arra gondolsz, hogy önállóan verziókezelhető részeket leszaggatni belőle, akkor való igaz, ez mondjuk következik abból is, hogy vannak ilyenek, hogy git mv. De félmegoldás van: submodule.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Jó tudni :)
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/
tompos
ui.: Szemely szerint nem vagyok egyik mellett sem.
- A hozzászóláshoz be kell jelentkezni
Ó, ez egy nagyon buta poszt :(
"1. Complex information model"
Ez igaz, de ez "and you need to know all of it." már nem. Tehát gyakorlatilag nem hátrány. A komplex modell meg előfeltétele a komplex működésnek. És a distributed mindig is bonyolultabb lesz, mint a centralizált, bármiről is legyen szó.
"2. Crazy command line syntax"
Ezt aláírom.
"3. Crappy documentation"
"They describe the commands from the perspective of a computer scientist, not a user."
Azt hittem verziókezelni jellemzően a programozók szoktak. Én ezzel teljesen elégedett vagyok, mármint a git dokumentáltságával, bármilyen problémámra első találat általában megfelelő.
"4. Information model sprawl"
Ez ugyanaz, mint az első poszt, és Google még mindig a barátom. Az információs modell bonyolultsága meg nem bug, hanem fícsör.
"5. Leaky abstraction"
Ugyanaz, mint a 2.
"6. Power for the maintainer, at the expense of the contributor"
Részben igaz, valóban bonyolultabb egy fokkal, mint az svn. De a hasonlata nagyon jó: "Git is a 4 handle, dual boiler espresso machine – when all they need is instant." Igen, és egy profi gépen talán nehezebben találod meg a gombot, de ugyanolyan könnyű megnyomni és utána nyomkodni amíg csak kávéra van szükséged.
"7. Unsafe version control"
ÚRISTEN TÖNKRE LEHET TENNI EGY REPÓT MÁSHOL EZ LEHETETLEN :::::!!!:!!444
De tényleg, nem egyszer veszítettünk el teljes svn repót mert valaki félrenyomott valamit. Nabumm. A gitnél az a szerencsés helyzet áll fennt, hogy ha valakinek a localjából vissza tudjátok állítani, akkor megmarad a history is.
"8. Burden of VCS maintainance pushed to contributors"
Ugyanaz, mint a 6.
"9. Git history is a bunch of lies"
Ez hülyeség. LEHET módosítani, de amíg nem pusholod valahova, addig az a te belügyed, utána pedig már nem illik.
"10. Simple tasks need so many commands"
Ez a példa meg szándékosan torzít.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
"De tényleg, nem egyszer veszítettünk el teljes svn repót mert valaki félrenyomott valamit."
Azt hogy sikerült? :) Mármint anélkül, hogy magába a repóba kézzel beletúrjon valaki valamit?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem tudom, a srác aki adminolta, branchelni akart, erre törölte a repót. Igen, ehhez különösen figyelmetlennek kell lenni, de azért előfordul.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
De most őszintén, egy copy funkcióval hogy lehet kiüríteni egy egész repot?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Nem tudom, de a kedvedért lehet megkérdem a kollégát, hogy sikerült a baleset.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Felesleges bonyolítás, nagyjából ennyi vele a probléma.
- A hozzászóláshoz be kell jelentkezni
http://www.freebsd.org/doc/en/articles/p4-primer/index.html ez sem tunik BSDL -nek.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
"Amig nem GPL, addig nem gond!"
--
</troll|8]>
- A hozzászóláshoz be kell jelentkezni