git vs. Bazaar

Flame

Hasonlitsuk oket ossze.
Melyiknek milyen elonye / hatranya van.
Foglalkozhatunk a "korejuk" keszult segito alakalmazasokkal is.

  • 2051 megtekintés

be kell vallani, hogy az utóbbi időben sokat fejlődött a git ezen a téren - egy évvel ezelőtt még mindig kb. pilótavizsga kellett a használatához.

igazából nehéz megmondani, hogy neked mi a jó. ha teheted, próbáld ki mindekettőt a napi feladataid közben, és dönts ez alapján...

Ehm.

Legyen ez a hello.c az elso commitban: 

#include <stdio.h>
int main()
{
        printf("Hello World!\n");

        return 0;
}

Amit aztán módosítsunk erre: 

#include <stdio.h>
int main()
{
        int i;
        for (i = 0; i < 10; i++) {
                printf("Hello World!\n");
        }

        return 0;
}

Aztán lássuk, mikor ki mit csinált: 

$ bzr blame hello.c 
1   sz@ | #include <stdio.h>
        | int main()
        | {
2   sz@ |   int i;
        |   for (i = 0; i < 10; i++) {
        |           printf("Hello World!\n");
        |   }
1   sz@ | 
        |   return 0;
        | }

Végülis igen, bár nem szabályos, de rá lehet erőltetni, hogy az a printf() hívás, vagy legalábbis az azt tartalmazó kódsor tényleg a második committal került be...
Node: 

$ git blame -w hello.c
^6e2c44a (sz 2008-03-07 23:59:28 +0100  1) #include <stdio.h>
^6e2c44a (sz 2008-03-07 23:59:28 +0100  2) int main()
^6e2c44a (sz 2008-03-07 23:59:28 +0100  3) {
a045c282 (sz 2008-03-08 00:07:08 +0100  4)      int i;
a045c282 (sz 2008-03-08 00:07:08 +0100  5)      for (i = 0; i < 10; i++) {
^6e2c44a (sz 2008-03-07 23:59:28 +0100  6)              printf("Hello World!\n");
a045c282 (sz 2008-03-08 00:07:08 +0100  7)      }
a045c282 (sz 2008-03-08 00:07:08 +0100  8) 
^6e2c44a (sz 2008-03-07 23:59:28 +0100  9)      return 0;
^6e2c44a (sz 2008-03-07 23:59:28 +0100 10) }

Hoppáhoppá, ahogy az a nagykönyvben meg van írva, mert az a kód bizony az első committal került be.
bzr-t nem tudom, hogyan lehet rávenni arra, hogy az ilyet tisztességesen felismerje. Aztán ott van még a git stash meg pár egyéb apróság, aminek hirtelen nem találtam bzr megfelelőjét... Bár azt meg kell jegyeznem, hogy eddig nem töltöttem a bazaarral fél óránál többet.

egyszerűen máshogy működik a diff algo. 

szilveszter$ bzr diff -r 1..2
=== modified file 'hello.c'
--- hello.c	2008-03-08 00:04:53 +0000
+++ hello.c	2008-03-08 00:05:47 +0000
@@ -1,7 +1,10 @@
 #include 
 int main()
 {
-        printf("Hello World!\n");
+        int i;
+        for (i = 0; i < 10; i++) {
+                printf("Hello World!\n");
+        }
 
         return 0;
 }

ami valahol nem is hülyeség, mert ugye azt az egy bizonyos sort cserélted le. persze a másik megközelítés meg az, hogy ez ugyanaz a sor, csak egy kis whitespace-t csaptál hozzá... szóval innentől kezdve ez megint csak vallási kérdés :)

Nem, a diff algoritmus ugyanaz, a git diff-je is ugyenezt mutatja.
Csak a git egyrészt okosabb, mert ezt képes felismerni, másrészt flexibilisebb, mert nem "vallási kérdést" csinál a dologból, hanem hagyja, hogy te döntsd el, mire is vagy valójában kíváncsi (-w opció, anélkül ugyanúgy viselkedik, mint a bzr).
A való életben pedig sokszor erre vagy kíváncsi. Például valahol egy függvényben volt 5 sor, amit eggyel beljebb kellett tolni, mert bele kellett tenni őket egy if-be. Aztán két hónappal később észreveszed, hogy abból az öt sorból a harmadik és negyedik elég vad dolgot csinál, és meg akarod tudni, hogy ki, mikor és mi céllal írta azokat. git-nél mindezt megtudni triviális, blame -w egyből megmondja, hogy ki és mikor, és ott a commit hash is, amiből már egyből meg is van a commit message. bzr-nél meg csak az van meg, hogy ki és mikor módosította azt a sort, aztán megnézve a commit message-t rá kell jöjjél, hogy az még bizony nem az, amit kerestél, úgyhogy lehet blame-elni az azt megelőző revíziót, ... és így tovább, ciklusban, ha neadjisten a kérdéses sorok többször voltak ki-be tologatva, amíg végre célhoz érsz.

bzr annotate --show-ids, és máris látod a revision id-ket, amik alapján pontosan be tudod azonosítani, hogy melyik commit alkalmával került bele az adott sor a kódba. a w kapcsolóval kapcsolatban értem a gondodat, és rosszul fogalmaztam: nem vallási, hanem technikai kérdés. szerintem egész egyszerűen még nem gondoltak erre a fejlesztők, és ha lenne rá igény, akkor biztos vagyok benne, hogy implementálnák. érdekes, hogy még nem reklamált senki ezügyben...

"-w opció, anélkül ugyanúgy viselkedik, mint a bzr"

Ez így ebben a formában nem teljesen igaz... dehát elég későre járt akkor már (;
Ebben a konkrét esetben a git -w nélkül tényleg úgy viselkedik, mint a bzr. De ha a file-t korábban átnevezték/mozgatták, akkor azt a bzr blame automatikusan leköveti, míg git blame-nek explicit meg kell mondani, hogy figyeljen oda, és kövesse le.

( ssikiss | 2008. 03. 07., p – 14:41 )

Nem ismerem a git-et, csak egy videót láttam, amiben Linus kifejti, hogy miért ubar. A bzt-t használom kb. fél éve, előtte svn és darcs volt.
Ha kell windows-on (is) nyomulnod, akkor git kilőve, ha sokat kell pöcsölnöd, akkor gondolom git.
Nekem azt tetszik benne a legjobban, hogy a bzr parancssora baromi egyszerű, repót lehet tárolni akár ftp tárhelyen is - nem kell szerver oldali támogatás. Ami nem tetszik, hogy pl. push utáni email értesítő küldéshez plugin kell, ill. nem vagyok a Python nagy barátja. Ha egy binárisban le lehetne tudni az egészet (darcs ilyen volt windows-on), akkor lennék a legboldogabb, mert akkor pl. hordozható lenne pendrive-on, és nem kellene mindenhova felrakosgatni, vagy bűvészkedni.