ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
HOVD 2009 - Kedvenc verziókezelő rendszerbazaar 7% (48 szavazat) codeville 0% (1 szavazat) cvs 9% (59 szavazat) darcs 0% (3 szavazat) git 27% (178 szavazat) gnu arch 1% (7 szavazat) mercurial 4% (26 szavazat) monotone 0% (2 szavazat) subversion 51% (337 szavazat) svk 1% (5 szavazat) Összes szavazat: 666
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 7% Összes szavazat: 567
Új felhasználók
InformációKövess minket!Partnerünk |
Team Foundation Server? Ennek hiányában kötelező pl. Visual SVN-ben gondolkodnom? Eléggé hiányos a lista. Cégeknél TFS elég gyakori, nem kellene lehagyni.
Lehetőséged volt javaslatokat tenni a HOVD előtt, mint ahogy minden évben.
Bazz, elfelejtettem javasolni a Perforce-t, mint minden nagyvallalati VS csucsat. :)
----------------------
while (!sleep) sheep++;
Vagy a clearcase-t. Nagyvallalatok nem igazan vannak jelen itt ;)
A CC nekem is volt eszemben, hogy javasoljam, de aztán rájöttem, hogy én biztosan nem szavaznék rá, szóval ha majd valakinek hiányzik akkor szól :D
szinten CC-t hasznalok nap mint nap, de nem a kedvencem. ;)
+1
A git tényleg ennyivel jobb a bazaar-nál, mint ahogy a szavazás mutatja, vagy más oka van a szimpátiakülönbségnek?
Jobban ismert.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Szerintem nem jobb, viszont gyorsabb
De persze ez nem a szavazásból derül ki, hisz mindkettő lényegesen jobb, mint a subversion, mégis az vezet (most éppen)
A Bazaar 2.0 elég sokat fejlődött ezen a téren, szerencsére.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Igen.
Érdekel, ne kímélj. :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
commit --amend, add -p, rebase -i, bash completion jut eszembe hirtelen a mindennap használtak közül, plusz a branchek koncepciója sokkal egyszerűbb és letisztultabb, de ennek ellenére (éppen ezért?) jóval többre képes.
Majd megnézem őket (nem ismerem a git-et, igaz a Bazaar-t sem annyira, mint kellene), de a git tud ftp/sftp-vel tárhelyre push-olni, ha ott nincs fent a git?
A branch-ek kezelése pedig jóval bonyolultabb a git-ben, mert aki nem ismeri a verziókezelőket, sokkal átláthatóbb, hogy egy könyvtár = egy branch. Pont nemrég volt erről szó, egy project kapcsán.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Passzolok, évek óta nem láttam ftp szervert. Ha tippelnem kellene, akkor inkább nem, mint igen.
Értem. Megnéztem a manualt és a bazaarnak ez a tulajdonsága nekem sokkal többet ér, mint azok az opciók, amelyeket felsoroltál. És amelyeknek egy részére biztosan tudnák mondani alternatívát, ha ismerném annyira a bazaart, amennyire nem.
De kinek mi a fontos, csak ne jelentsük ki egyértelműen, hogy egyik jobb, mint a másik.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Meglehet. commit --amend nyilván workaroundolható egy uncommit-commit párossal, de rebase -i-re és add -p-re nem látok még workaroundot se.
Ezek nélkül meg hiába megy az sftp push, nem nagyon lenne mit pusholni (;
Nem tudom, nekem eddig mindig volt mit. Elfogadom, hogy ezekre nektek nagy szükség van, érdekes, hogy nekünk eddig nem került elő a hiánya.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Amíg csak svn volt, nekem se tűnt fel...
"A branch-ek kezelése pedig jóval bonyolultabb a git-ben"
Amikor bzr-nél még vmi URL-t is meg kell adni egy branch létrehozásakor?
"sokkal átláthatóbb, hogy egy könyvtár = egy branch."
Szerintem pont ez teszi bonyolulttá és nehézkesen használhatóvá.
Annak, aki nem ismeri a verziókezelő rendszereket, sokkal bonyolultabb, hogy egy könyvtárban ott van az összes branch, mint az, hogy ezek a fájlrendszerben is elkülönülnek. És ez nem tőlem származik, hanem egy nagyobb fejlesztés átállásakor merült fel.
Az URL-es nyűgödet pedig nem értem pontosan.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
"Annak, aki nem ismeri a verziókezelő rendszereket, sokkal bonyolultabb, hogy egy könyvtárban ott van az összes branch, mint az, hogy ezek a fájlrendszerben is elkülönülnek
Ami természeténél fogva jóval nehezebbé teszi a branchek közötti váltást, meg úgy általában a branchek kezelését.
"Az URL-es nyűgödet pedig nem értem pontosan."
Én se. bzr docban láttam vmi bzr branch sftp://host/patch/branch parancsot, nem is akartam hinni a szememnek.
Miért nehezebb a path-ba beírni a branch nevét, mint kiírni azt, hogy egy adott könyvtárban található összes branchból melyiket választod?
Gondolom, ha közvetlenül a szerverről akarsz elérni valamit. Érdekes, itt pl. simán megy a "bzr branch egyik masik" is. Vagy neked, ha távoli szerverről szedsz le branch-ot, nem kell kiírni a szerverhez vezető URL-t?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
"Miért nehezebb a path-ba beírni a branch nevét, mint kiírni azt, hogy egy adott könyvtárban található összes branchból melyiket választod?
Ezt most nem egészen értem, szóval tisztázzuk a fogalmakat: az "egy adott könyvtár" alatt itt most egy git repositoryt értesz? Ha igen, és éppen a repository gyökerében vagy, akkor semmivel sem nehezebb. De ha nem ott vagy, hanem egy branchben, több alkönyvtár mélyen? git esetében triviális, ugyanúgy, mint a repo gyökerében. Viszont negyed óra nem volt elég rá, hogy rájöjjek, bzr-ben hogyan lehetne megoldani a gyökérbe visszamászás nélkül.
blame -w, diff -M/-C
A "blame -w" -ről volt szó régebben itt a HUP-on, olvass vissza.
Szóval mit szerettél volna mondani?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Munka közben délután igencsak jól jött az általános esetben (értsd: nem csak git mv-vel átnevezett file-ok esetén) is működő diff -C/-M, gondoltam bővítem vele a listát. Aztán közben láttam, hogy a blame -w is kimaradt a "miért jobb a git, mint a bzr" felsorolásból, ezért megemlítettem azt is.
szerk.: és a diff --color-words is kimaradt, szöveg összehasonlításakor életmentő. De feltételezem, hogy ez vmi external diff utillal megoldható.
ftp://ftp.fsf.hu/contrib/flosszine/VajnaMiklos-GIT.mpg
--
Írj egy e-mailt, ha itt bármi hibát találsz. ^ ^
azzal, hogy svn-t hasznalok ennyire le vagyok maradva, vagy mi? tobbre szamitottam ;)
Szerintem már csak a támogatottsága miatt ilyen népszerű az svn. A következő generáció megérkezett, csak lassan fogadják be :)