Bazaar kérdések

Fejlesztés

Sziasztok!

Lenne pár kérdésem a Bazaar verziókezelő rendszerrel kapcsolatban.
Ha mondjuk fejlesztek egy Drupal modult, akkor azt két verzió alá készítem (Drupal 5 és 6), ezek az én olvasatomban külön branch-ek lesznek. Ez annyit jelent, hogy a szerveren (ahol publikálom), készítek egy könyvtárat a projectnek, azon belül egy könyvtárat a Drupal 5, egy másikat pedig a Drupal 6 számára? Hogyan tudatom a rendszerrel, hogy ez nem két külön project, hanem egy project két branch-e, ha a project főkönyvtárában nem jön létre a .bzr könyvtár?

Köszönöm a válaszokat, igyekeztem minél többmindent felfogni a használatából, de nem mindent sikerült, különösen az "elosztott használat" résznél.

  • 3185 megtekintés

( gabor v | 2009. 03. 06., p – 09:03 )

Szerintem sehogy, a branchek fuggetlenek, a "rendszernek" nem kell tudnia, hogy ez egy project ketto branch-e. Igazabol meg egy konyvtarban sem kell lenniuk, oda teszed oket ahova akarod, akar masik gepre.

Persze ettol meg ugyanugy tudsz majd pl. egy revision-t merge-lni egyikbol a masikba.

Szerk.: ha a szerveren ahol publikalod fut valami web-interfesz a bazaar-hoz, mint pl. Launchpad-on a loggerhead, akkor annak a konfigjaban kell megadnod, hogy melyik branchek tartoznak egy projekthez.

Egy darabig kerestem a 'branches'-t, szoval ez nem a main bazaar resze, a 'bzrtools'-ban van. A rovid help-je szerint csak vegigmegy egy konyvtarstrukturan es branch-eket keres ott. De nem biztos, mert nekem hasznalhatatlan, 2.5GB memoriat akar lefoglalni.

Ha mindenkeppen ossze akarod kapcsolni a branch-eket valahogy, akkor esetleg nezd meg ezt: 'bzr help repositories', en sohasem hasznaltam kozos repot a branch-eknek, szoval nem tudom mi az elony vagy hatrany.

Igazabol bazaar-ral az ember lepten-nyomon hoz letre brancheket, szoval nem csak egy stable meg egy development branch van, hanem ha valami kicsit nagyobb valtoztatast akarsz csinalni es szet akarod szedni tobb revision-ba, akkor mar erdemes egy branch-et csinalni neki, aztan ha mar kb. kesz van es stabil, akkor merge-elni a main branchbe.

(Nem vagyok egy Bazaar poweruser, szoval szivesen veszem ha valaki kijavit ha esetleg valahol hulyeseget irok...)

Ha esetleg használod, akkor tudnál mutatni egy példa "munkaciklust", vagyis munka kezdetekor, közben és végén milyen parancsokat adsz ki? Nem tudom, "szabályosan" használom-e, és jó lenne látni egy "working cycle" -t, de nem találtam sehol.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Hat ugye az a helyzet, hogy ez erosen fugg attol, hogy ki milyen fejlesztesi modellt hasznal, mert a bazaar tobbet is tamogat.

En ugy hasznalom, hogy van egy kozponti repo (launchpad) amiben a 'stable' meg a 'devel' branch van, es a sajat gepemen vannak azok a branchek amiket eppen javitok/bovitek. Ezek vagy a 'stable'-bol vagy a 'devel'-bol szarmaznak, tipikusan ha a 'stable'-be is bele fog menni, akkor onnan (es majd atvezetjuk a 'devel'-be is), kulonben a 'devel'-bol. Szoval ha pl. egy bugot javitok, akkor

bzr branch <stable> stable-1
cd stable-1
# Bug javitasa
bzr commit
# Tovabbi bug javitasa
bzr commit
...
# Amint ismet online vagyok
bzr push

Ha a bug javitasat at akarom vezetni a 'devel' branchbe

cd ..
bzr branch <devel> devel-1
cd devel-1
bzr merge -c <revision> ../stable-1
bzr commit
bzr push

A 'bzr push' utan a lokalis branch torolheto, de erdemes mindig tartani egy copy-t a lokalis gepen, hogy kelljen mindig 'bzr branch', hanem csak egy 'bzr pull' eleg legyen.

Persze a 'bzr branch' es a 'bzr push' kozott esetleg mar valtozott a branch a Launchpadon, olyankor kiveszek egy szuz branchet Launchpadrol, abba mergelem a sajatomat, aztan 'bzr push', a sajatot meg lehet torolni.

Ha egyszerre tobb fuggetlen dolgon dolgozom, akkor tobb branch van a lokalis gepemen, <stable>-1, <stable>-2, etc.

Szoval kb. csak minimalis feature-oket hasznalok, nekem a lenyeg, hogy legyen offline commit, mert sokszor dolgozom utkozben, kavezokban, eloadasok alatt, repulogepen, etc.

A repository használat annyit tud, hogy egy közös struktúrában tárolja az alatta lévő brancsok adatait. Én ennek gyakorlati jelentőségét akkor láttam, amikor van egy olyan (központi) bzr szerver, ahol nincsen szükség arra, hogy a tárolt fájlok fizikailag is meg legyenek (mert pl. nincsen fejlesztés, csak tárolás), mert lehet repót csinálni valami --no-trees opcióval. Így helyet lehet megtakarítani, mert csak .bzr könyvtárak vannak.

Nos, úgy tűnik, hogy a bzr init-repo pont arra való, amire szeretném, vagyis egy adott fejlesztés több ágát lehet összefogni vele. Azt még pontosan nem tudom, hogy miért jó így összefogni őket, de próbálom kibogozni a lényeget.

Szerk:

When two branches of the same project share a repository, there is generally a large space saving. For some operations (e.g. branching within the repository) this translates in to a large time saving.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2009. 03. 08., v – 15:09 )

próbáltam a local commit-ot, de ezt a hibaüzenetet kaptam:

bzr: ERROR: Cannot perform local-only commits on unbound branches.

Nem igazán találtam a Google-val segítséget arra, hogy mi lehet a baja, csak legfeljebb annyit, hogy a bind/unbind -hez lehet köze, annak viszont nem tudom, mi a szerepe.
Valaki esetleg tudja ezekre a választ?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Most kipróbáltam egy tesztkörnyezetben, repository-nak egy másik könyvtárat használtam. Letöltöttem belőle a branch-et (bzr branch), módosítottam az abban szereplő egyetlen fájlt, majd local commitolni szerettem volna, de ugyanez a hibaüzenet fogadott. Semmi más komolyabb műveletet nem végeztem, ezeken kívül egy bzr log és bzr status volt.
A Bazaar verziója 1.6.1, Ubuntu 8.10

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Nem tudom mi nalad a baj, en igy szoktam csinalni, rendesen mukodik:

## Create a branch in a repo
cd /tmp
mkdir test-repo
mkdir test
cd test
bzr init
bzr push /tmp/test-repo/0.1-main

## Don't need it any more
cd ..
rm -rf test

## Update and local commit
bzr branch /tmp/test-repo/0.1-main
cd 0.1-main
echo 'Hello world!' > foo
bzr add foo
bzr status
bzr commit -m "Added foo"

## Check that the repo is not affected
cd ../test-repo/0.1-main
bzr log
cd -

## Update repo
bzr push /tmp/test-repo/0.1-main

## Check that the repo was updated
cd ../test-repo/0.1-main
bzr log

## Clean up after example
cd
rm -rf /tmp/test /tmp/test-repo /tmp/0.1-main

Ööö... most látom, rosszul fogalmaztam. Ez a része nekem is jól működik, azóta megelégedéssel használom a bzr-t, csak próbálgattam a kézikönyv 

bzr commit --local

parancsot, amely elvileg csak a helyi repóban lenne commit, a távoliban nem, és ez nem működik.
Rosszul fogalmaztam, a "bzr commit --local" -ra gondoltam most helyi commit alatt.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Aha, szóval akkor arról van szó, hogy a "commit --local"-nak semmi értelme ha nem volt előtte "bzr bind", mert úgyis local lesz a commit.

Ha "bzr bind" volt akkor a lokális branch-ed hozzá van kötve egy távolihoz, vagyis minden commit automatikusan megy a távoliba is. Kivéve, ha "bzr commit --local"-t nyomsz, mert akkor csak a helyibe megy.

A bind-nek az az értelme, hogy ha a távoli branchbe nem tud bemenni a commit, akkor nem is hajtódik végre, a lokálisba sem megy be. Viszont --local-lal tudsz lokális commit-ot csinálni ilyenkor is. (A --local lényegében olyan mintha kiadnál egy "unbind, commit, bind" sorozatot.)

(Nem próbáltam most ki.... és nem szoktam bind-delni, de szerintem így működik.)

( nevergone v | 2009. 03. 09., h – 11:25 )

Újra előszedtem a Bazaar Howto szócikket a HUPWiki-ben, mivel összeállítottam magamnak egy rövid jegyzetet, amely alapján bárki képes lehet a Bazaar verziókezelő rendszer alapvető használatára. Ez a jegyzet fog példákkal kiegészítve felkerülni a szócikkbe, ha valaki úgy gondolja, bátran segíthet benne. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2009. 03. 13., p – 10:04 )

Azt hogyan tudom megnézni, hogy egy adott fájl, vagy annak egy adott sora melyik commit-okban változott? Probáltam a bzr annotate -t, de nem adott értelmes eredményt.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2009. 03. 14., szo – 09:44 )

Tudtok PHP alapú webes interfészt a Bazaarhoz? Valami olyan kellene, ahol láthatóak a kommit logok, változások, stb. Amit találtam eddig, az mind Python alapú volt, és az nem jó nekem.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Loggerhead nagyon jo, de az tenyleg Python. Viszont a sajat portjan hallgatozik, nem kell hozza webserver. Persze ettol nem lesz konnyebb feltenni egy site-ra ahol csak php-t tamogatnak....

Egyebkent ha regisztralsz a launchpad-ra es oda push-olod a branch-eidet, akkor kapsz szep webes interface-t is.

Igen, a launchpad adott helyzetben jó megoldás, de vannak privát céges projectek, és azokat nem lenne tanácsos kivinni más szolgáltatóhoz. Viszont egy webes rendszer is jó lenne az áttekintéshez.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ha nincs más, akkor "felerőszakolható", csak szerettem volna elkerülni, mert nem igazán kedvelik az ilyen igényeket. De látom, te sem tudsz más megoldásról, szóval akkor marad ez.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2009. 03. 23., h – 20:37 )

A Bazaart hogyan lehet teljesen elosztott módon használni? Vagyis nincs központi szerver, amely tárolja a repo-t.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Igen, ezt a részét átnéztem, és többé-kevésbé le tudtam magamnak fordítani magyarra, de mégsem tiszta a működési elve és használata. Az megvan, hogyan kell a bazaart használni központi tárolóval, de most olyan projectet próbálnánk ki, ahol nincs központi tároló, hanem mindenki a saját gépén tárolná a dolgokat.
És itt jön a kérdés, hogy ilyenkor miben változik a bazaar használata a "központi tárolós" megoldáshoz képest, hogyan adom meg, hova "push"-oljon, hogyan kezelem a branch-okat, stb.
Valószínűleg az egyik fő problémát az okozza, hogy még nem használtam elosztott módon verziókezelő rendszert, ezért nem látom át ezt a logikáját.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Központi repó hiányában az a legfontosabb kérdés, hogy hogyan tudjátok/akarjátok utaztatni egymás közt a változásokat. Én alapvetően két fajta módról tudok. Van, amikor direktben éritek el egymás repóját svn, ftp, http, fájlrendszermegosztás útján. A másik, amikor send-el küldözgettek egymásnak pöcsöket.
Ezek leírása van a linkeken.

Hát ez nem biztos, hogy alternatívája annak, amire te gondolsz. A git-ben ez hogyan van megoldva? Hátha annak a segítségével közelebb jutok itt is a megoldáshoz.
Mondjuk kissé bánom azt, hogy a Bazaar kiegészítések szinte csak Pythonban vannak, ez nem jelent túl jót annak, aki nem akar csak ezért belemélyedni a Pythonba. Na meg az is kissé kellemetlen, hogy a Launchpad-on kívül nem igazán használja nagyobb project.
Na de ez van, végülis nekem (egyelőre) megfelel, valamelyest sikerült is megismernem, migrálgatni pedig nem akarok.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2009. 03. 29., v – 00:23 )

No úgy néz ki, nekiállok kidolgozni egy átállást git-re, a kezdeti lelkesedés után jött az, hogy úgy látom, jóval kevesebb segédeszköz van Bazaar-ra, mint git-re. Elég csak összevetni ezt ezzel. Szóval ott tartunk, hogy a Launchpad és a Python marha jó dolog, de kb. ott meg is áll a tudomány.
Most még meglátom, mennyire lehet "kibekkelni" parancssori eszközökkel, mert a bzr-t viszont elég jól megismertem és megkedveltem... csak úgy tűnik, elmaradásban van.
Akár lesz átállás, akár nem, akár a Bazaar Howto -ba belekerülnek még azok a dolgok, melyeket - többé-kevésbé - megértettem és hátravannak.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Csak csendben szólok - ha valakit érdekel - hogy a kezdeti problémákat áthidalva maradtam továbbra is a Bazaar-nál, mert az nekem már nagyon kézreáll, és továbbra is egy jól használható verziókezelő rendszernek tartom. Bár az továbbra is érdekelne, hogy patch-managment használatával hogyan lehet teljesen elosztott módon használni, a legtöbb leírás ezt pár mondattal elintézi.
Lassan folytatom a HupWiki-be a "firkálgatást", van még mit. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Ha jól láttam, nem tud olyan szintű patch-kezelést, mint a git, de csak érintőlegesen foglalkoztam eddig vele, mivel egyrészt a központi repó megoldható volt, másrészt pedig az új Ubuntuban már elég friss bzr lesz (1.13.1), a mostani 1.6 helyett.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Igazán csendben jegyzem meg, hogy a számításom bejött, a PQM igazán ütős megoldást ad a patch-kezelésre, sőt rendelkezik pár érdekes tulajdonsággal (pl. saját webes felület) is. Csak egyrészt ebben az Ubuntuban még kissé "öregecske", másrészt pedig nagyon kevés az elérhető információ a használatáról, pedig a kézikönyv igazán foglalkozhatna vele komolyabban is.

Plusz egy pont a hangulatomnak. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2010. 01. 20., sze – 00:08 )

Mi a különbség a "checkout" a "pull" és a "branch" között? Egyszerűen nem bírok rájönni, mikor melyik lenne a célravezető.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Szerintem 'checkout'-ra nincs igazán szükség. Egyébként 'bzr help checkouts' egészen jól leírja, hogy mi az. Majdnem ugyanaz mint a 'branch', csak csinál néhány extra dolgot, pl. 'bind'-ol by default, meg csinálhatsz lightweight checkout-ot. A 'pull' egyszerűen frissíti a lokális branch-edet a megadott másik (vagy a default) branch-nek megfelelően.

Én a 'branch'-et akkor használom, ha új working copy-t akarok csinálni, pl. valami új dolgon kezdek dolgozni, új feature vagy új bug. A 'pull'-t meg akkor, ha közben valaki más frissítette a master branch-et, ez up-to-date állapotba hozza a lokális branch-et, feltéve, hogy nem divergáltak, mert akkor 'merge' kell.

A 'co'-nak számomra egy értelme van.
Ha csak apró dolgot akarok javítani, és nem kell full history akkor a 'bzr co --lightweight' hasznos, mert gyors. Viszont pl. egy egyszerű 'diff'-hez is szükség van a master branch-re.

Köszönöm, igazából a checkout lényege nem volt meg, mert a leírás valahogy úgy mondta el, hogy nem értettem meg a különbséget. De így most már értem a lényeget, köszönöm. :)
(Azóta is bzr.)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."