Co (ne)používáte pro sledování bugů a správu kódu a proč? (diskuse)

[Messa]

Používám Trac a SVN (jak v práci tak i občas soukromě), obojí je fajn a jednoduše pochopitelné. Trac lze propojit s SVN a možná i s jinými verzovacími systémy - na netu jsem viděl něco co nápadně připomínalo Trac a běželo to nad Mercurialem. Trac běží v Pythonu, umí pluginy a upravit vzhled šablonami (btw. používá Genshi). Tedy jestli jsou tohle ty nástroje které máš na mysli.

[Messa]

Součástí Tracu je i wiki.

Řekl bych, že většina open-source projektů, pokud používá systém pro verzování kódu, tak SVN (odvážlivci git nebo něco jiného), a pokud používá issue tracker, tak Trac, Bugzillu, případně SourceForge. U Debianu nebo tuším i Gnome se používá RT od Best Practical Solutions, pořádně ani nevím co to je :), ale je to také něco pro sledování požadavků a vypadá to celkem advanced. A že se jedná o "free" open-source projekty - tím spíš, jejich řízení je stejně složité jako u těch komerčních. Na CVS lidi povětšinou nadávají a na SourceSafe taky (prý je dost zaměřené na Visual Studio, říkal bydla)

A vůbec, Dejve, když tu ze čtenářů taháš jejich znalosti, napiš sám své zkušenosti s SCM a RT systémy, byť jen z pohledu uživatele

(Sorry za dvojí příspěvek, ale mě prostě spousta věcí napadne až po odeslání. Taky by tu mohlo být něco jako editace již poslaných příspěvků, většina webových fór to umí a problémy s tím myslím nejsou.)

[Luk]

pokud používá issue tracker, tak Trac, Bugzillu, případně SourceForge

Anebo třeba Mantis. Bugzilla je uživatelsky nepřívětivá a SourceForge zase šíleně pomalý (aneb "nesnáším AJAXové chrlení!").

[Messa]

K jednomu Mantisu mám také přístup, nevím jestli je ale nakonfigurovaný na využití všech možností Mantisu. Na první pohled umí narozdíl od Tracu připojit ke komentáři bugu soubor a linkovat bugy mezi sebou nebo vytvořit "podbug", ale zase při psaní nevidím možnost formátování textu (tučný, nadpis apod.) a nevím, jestli lze propojit se systémem pro verzování kódu (VCS, např. SVN).

[Luk]

zase při psaní nevidím možnost formátování textu (tučný, nadpis apod.)

Možná to opravdu neumí (verze 1.1.x v tomto ohledu neznám, používám stále ještě 1.0.x).

nevím, jestli lze propojit se systémem pro verzování kódu (VCS, např. SVN).

Umí CVS a SVN. A obecně to není žádné ořezávátko (features).

[Let_Me_Be]

Skoda ze tyhle light-systemy neumi GIT. Zacina mi vadit pomalost SVN ale zase na druhou stranu Bugzillu fakt pouzivat nechci.

[Michal Čihař]

Upravit Mantisí hook pro svn na git by IMHO neměl být problém.

[David Jaša]

zase při psaní nevidím možnost formátování textu (tučný, nadpis apod.)

Možná to opravdu neumí (verze 1.1.x v tomto ohledu neznám, používám stále ještě 1.0.x).

K čemu je to vlastně dobré? Připadá mi, že bohatě stačí zobrazení jako prostý text neproporcionálním písmem...

[David Jaša]

A vůbec, Dejve, když tu ze čtenářů taháš jejich znalosti, napiš sám své zkušenosti s SCM a RT systémy, byť jen z pohledu uživatele

BT systémy mi přijdou tak nějak všechny stejné - všechno to má nějaké políčko pro nadpis, popis a stav, možnost přiložit soubor a označit jako duplikát a při změně mi to pošle email. Zbytek mi nějak splývá a rád bych, aby přestal.

S SCM mám ještě menší zkušenosti, checkout u ne-SVN provádím zkopírováním příkazu ze stránek projektu a přístup pro zápis mám pouze k cs.po v jedné svn, takže mi už ani nemá co splývat.

[anicka]

odvážlivci git

Proc? Vzdyt git (nebo cogito, ale dneska uz je to skoro fuk) je na bezne pouzivani daleko jednodussi nez SVN, prave proto, ze nepotrebuje zadnou centralni spravu. Vlastne myslim, ze SVN uz dneska pouzivaji lidi bud jen z historickych duvodu, nebo protoze jsou lini ucit se neco noveho. Dobre jim tak, ale skoda, ze odrazuji i ostatni

pokud používá issue tracker, tak Trac, Bugzillu

Odvazlivec je spis ten, kdo pouziva bugzillu. Pece o bugzillu je nejvetsi adminske peklo, ktere znam, a to jsem zvykla hackovat perlove moduly.

Co do funkcnosti a snadne udrzby se mi docela libi Mantis.

[thingie]

Git je na používání mnohem jednodušší než SVN, jenom to lidi nechtějí vidět, protože se jim furt říká opak :o)

[thingie]

Používejte git, pravítkuje.

[RapMan]

Na spravu kodu Subversion, k tomu webove rozhrani GFORGE. Proc? Protoze to tak rozhodli nadrizeni z Nemecka.Jedna se o programovani ve Visual Studiu, do VS je primo subversion plugin. Celkove zatim spokojenost.

[vlasta neubauer]

v práci a trochu i doma používám Subversion a chystám se na ni našroubovat i Trac. celkem známý issue tracker je také Mantis (psaný v PHP). mám takové tušení, že umí spolupracovat se starou CVS

[alfonz]

lidičky jak je to s Bazaarem/launchpad.net?

[denix]

pouzivam SourceForge enterprise - vmware image, spokojenost

[alblaho]

Já jsem fanda Bazaaru, umí to co SVN +bezva věci navíc (merge tracking, lokální logy a ta distribuovanost...). Ovládání je skoro kompatibilní se SVN.

[Martin Böhm]

Já taky. Je sice trochu pomalejší, ale ta přívětivost to vyvažuje. Z bzr jsem se vše potřebné o tvorbě, větvení a merge kódu naučil za odpoledne a z gitu umím stále jen to clone :o) ( To je samozřejmě jen a jen mou blbostí.)

[Martin Böhm]

Respektive mou neschopností najít si dobrou dokumentaci. Naštěstí už jsem to napravil.

[freshmouse]

Z bzr jsem se vše potřebné o tvorbě, větvení a merge kódu naučil za odpoledne

Já právě uvažuju, že bych se měl nějaký podobný systém naučit používat. Zrovna Bazaar se mi líbí. Nemůžu ho samozřejmě posoudit podle technické kvality, když těmto systémům nerozumím, ale třeba dokumentace vypadá dost přívětivě, takže by opravdu nemuselo být těžké naučit se s podobným systémem pracovat...

Mimochodem, používáte takové systémy i pro osobní potřebu (kód, na kterém děláte jen vy)?

[Milan Horák]

Já používám SVN pro svoje projekty, a to jak 'programovací' tak třeba i elektronická schemata. SVN server nemám a Klenot jej zatím nenabízí, takže používám OpenSVN.

[Käyttäjä 11133]

No já používám SVN.. A proč? Protože ho používají všechny projekty na kterých nějakým způsobem kooperuji. Pokud bych si chtěl rozchodit vlastní server tak bych sěl buďto z lenosti do SVNka, nebo bych se naučil s GITem.

[Stanislav Bohm]

Ja jsem ted migroval svuj osobni projekt ze SVN do Bazaaru a jsem maximalne spokojeny. Dalsi projekty uz budu asi zaklat v nem. Asi pred pul rokem jsem si hral s Mercurialem, ale mel jsem nejake potize s import scriptem ze svn, ale asi spise moje neschopnost. Co si tak pamatuju tak to bylo Bazaaru velmi podobne. Od GITu me zatim odradilo to ze neni (udajne) bezproblemovy pod Windows. Me plne staci jen funkcnost pod Linuxem, ale nechci omezovat pripadne dalsi ucastniky na mem projektu

[MJ]

Pokud vím, MSysGIT (port GITu pro Windows) už funguje velice pěkně, mí wokenní kolegové si ho pochvalují.

[frdrx]

Neváhej. Sice nejsem žádnej programátor, ale co jsem se naučil používat bzr, změnil se mi život. Verzuju si s tím skoro všechny věci na kterých pracuju a už bych bez VCS pracovat nechtěl. Jo, používám bzr pro osobní potřebu. Je to skvělá věc na diplomku, překlady, korektury, články, prostě cokoli, zvlášť ve spojení s (La)TeXem a R. Všechno stranou a naučit se bzr. Proč zrovna bzr? Nevím, prostě mu fandím.

[Messa]

Pro osobní potřebu taky, ale ne nutně pro všechno. Hlavně jsem paranoidní a furt mám strach, že jsem si něco omylem přepsal nebo smazal, takže se s VCS aspoň můžu podívat na všechny změny. A i když si to přepíšu úmyslně, můžu se vrátit. A taky občas potřebuju mít jednu věc na více počítačích a VCS je na takovou synchronizaci asi nejlepší.

Bylo by fajn, kdyby nějaké verzování uměl už filesystém, aspoň by pak nikde nepřekážel repositář, ale zase... mělo by se to chovat jako SVN, nebo jako (doplňte cokoliv jiného)?

[frdrx]

Jestli by bylo praktické cpát tuhle funkčnost do filesystému opravdu nevím, ale mně repozitáře (bzr), nepřekáží, protože jsou ve skrytých adresářích. Navíc není problém mít repozitář někde úplně jinde. Já si třeba verzuju /etc a repozitář mám ve /var/backups. Paráda. Ještě by to chtělo dát /var na jiný disk.

[Käyttäjä 11133]

Tohle by mohlo vyřešit fuse.

[MJ]

Verzovaný filesystem asi ano, ale to, co většina lidí od správce verzí chce, není verzování jednotlivých souborů, ale celého podstromu (řekněme odpovídajícího jednomu projektu), přičemž změny jsou seskupeny do nějakých logických celků (commitů, changesetů, či jak tomu který VCS říká). To pomocí obvyklých filesystémových operací rozumně udělat nedá.

[Luk]

Já to řeším pomocí incronu. Jednoduše tak, že se při události IN_CLOSE_WRITE (zavření souboru po zápisu) spustí příkaz k vytvoření nové verze (zatím používám darcs). Nepříjemné je, že se to musí nastavit pro každý adresář zvlášť (zatím jsem se nedostal k vytvoření verze incronu, který by podporovala práci s celými podstromy - snad by to mělo být nejpozději za měsíc). Další problém spočívá v tom, že by se do vytvoření verze nemělo v souboru nic měnit (běžně to není problém, ale potenciální riziko tu je), aby se neporušila konzistence.

[David Jaša]

(zatím používám darcs)

V duchu nadpisu se zeptám: proč darcs a proč zatím?

[Luk]

Protože už ho používám hezky dlouho a v té dávné minulosti mi vyhovoval. Jenže postupem času se ukázalo, že mi až tolik nevyhovuje (třeba když jsem chtěl vytáhnout nějakou verzi a ono to chroustalo skoro půl hodiny - nedivil jsem se, je to chování "by design"), proto plánuji přechod na něco jiného. Jestli to bude SVN (který už teď stejně zhusta používám) nebo něco úplně jiného, to se ještě uvidí.

[Josef Kufner]

touch /.commit ?

[Luk]

Nerozumím

[pavlix]

fresh....

Bazaar umí letacos, ale ukrutně pomalu. Git to umí taky, jen mnohem efektivněji. Doporučuju zkusit.

Pro osobní potřebou používám... ze začátku subversion (neúspěch, hrozné problémy, když nebyl notebook na netu a nemohl na server), potom bazaar, fajn, ale zdržoval. Takže nakonec to vyhrála ta Linusova hračka :).

[MJ]

Na sledování bugů Bugzillu, ale to spíš ze zvyku než že by se mi nějak moc líbila (či spíš nic jiného mne nepřesvědčilo o tom, že by bylo řádově lepší).

Co se správy verzí týče, vyhrává s obrovským odstupem GIT – jak tím, co umí, tak tím, že se příjemně ovládá, a v neposlední řadě svou rychlostí (taktéž má narozdíl od mnohé konkurence velice rozumný a jednoduchý formát repository).

[disorder]

aj mne sa zapacil git viac nez bzr a zrovna nedavno som narazil na tento pekny blogpost

pre buduce projekty mam pripravene riesenie trac + git plugin

[tomm]

CVS + CvsTrac + CvsWeb + CvsSpamm + StatCVS.

[Miloslav Ponkrác]

Já jsem začal používat SVN a pro své účely jsem se vrátil k CVS. Proč? Protože CVS chodí všude i na platfromách, kde SVN ne. Protože když chci CVS zazálohovat, tak prostě zazipuji jeho adresář a je to. Protože CVS má mnohem širší paletu možností, jak přistupovat k repository - a pro domácí vývoj klidně rovnou do adresáře. A protože výhody SVN nejsou tak podstatné pro to co potřebuji. V krajním případě do CVS repository zasáhnu i ručně, u SVN nikoli, protože se v tom nevyznám.

Spíš je to ale tím, že SVN se nesnaží o nic revolučního oproti CVS - SVN se snaží být CVS verze 2.0. Ale vývoj CVS taky neustrnul a je daleko komfortnější a s mnohem bohatší sadou příkazů, než nedávno. Myslím si, že pokud přestoupit, tak na revolučnějšího a propracovanějšího, než CVS/SVN v podstatě se stejnou filozofií. Takže přemýšlím, GIT to rozhodně nebude, to je typický Linusův rychlokvašák a i když je protěžovaný, nemyslím, že je to správná cesta.

Takže plánuji seznámení s dalšími VCS a uvidí se. Pokud máte někdo dobrý tip...

[Filip Jirsák]

GIT to rozhodně nebude, to je typický Linusův rychlokvašák

Podobně jako Linux, že?

[freshmouse]

Neznám studenta, který by svou školní práci neděkal ve spěchu a na poslední chvíli.

[MJ]

Takže přemýšlím, GIT to rozhodně nebude, to je typický Linusův rychlokvašák

To se pozná jak?

Mě naopak přijde, že GIT má narozdíl od většiny ostatních systémů velice promyšlenou architekturu repository. Implementace sice zpočátku vznikala trochu živelně, ale na struktuře repository se od té doby změnilo pramálo a myslím, že se velice osvědčila.

[pavlix]

Njn, Linus prohlásil, že napíše lepší správu verzí než svn apod do dvou týdnů.

A měl pravdu.

Dál není co dodat.... časem se z toho stal systém nejenom lepší... ale i opravdu dobrý... (jen můj názor).

[Miloslav Ponkrác]

Já bych to řekl takhle - co Linus dělá dobře dělá, kritika se nepřipouští. Chci si vybrat produkt, o kterém si přečtu - tohle je dobré, tohle je špatné, tohle je na něm skvělé a tohle je to tálně na velké kulové. Protože každý VCS systém je jenom kompromis - máte x různých konceptů VCS systémů, kde je x naprosto přesvědčených zastánců, že ta jejich koncepce je správná. A nerozhodnete, protože správnost koncepce je věcí konkrétní potřeby těch kterých vlastností. A já se rozhodl, že GIT ne.

Jinak velmi děkuji za několikanásobné doporučení GITu, když jsme řekl, že ho nechci. Jeden z důvodů, proč ho nechci je, že je to rychlokvaška a klidně vysvětlím proč. První priorita VCS u mě je multiplatformovost - což předkládá již prvotní navržení jako multiplatformového systému. GIT byl nahonem napsán jako náhrada pro kernel - a tak je jeho architektura původně psána POUZE PRO unix-like systémy. Teď se to nějak honí, takže existuje GIT pro Windows, ale pod Cygwinem, a nativní GIT, který ale není dotáhnutý. Obě verze pro Windows jsou pomalejší, než verze pro Linux. GIT prostě má problémy s multiplatformovostí - a já vzhledem k tomu, že lítám mezi několika operačními systémy nechci a nemůžu zvolit VCS, který je v zásadě prostě navržen metodou "za pár večerů to spíchnu" a někde se tohle rychlokvašení projevit musí.

První priorita pro mě je VCS, který nemá problémy a je od začátku plně multiplatformově navržen - tj. od začátku bez problémů běží nejen na unix-only a ostatní je nějak zmastěno, což je právě GIT.

[Filip Jirsák]

Já bych to řekl takhle - co Linus dělá dobře dělá, kritika se nepřipouští.

GIT to rozhodně nebude, to je typický Linusův rychlokvašák

Tohle ale není kritika, to je plácnutí do větru.

Teď už jste se pokusil alespoň něco napsat, ale je to poněkud zmatené – pod slovním spojením „je to typický Linusův rychlokvašák“ si rozhodně nepředstavím, že to není multiplatformní. Pak píšete, že na VCS je důležitá koncepce, ale dál kritizujete jenom nemultiplatformnost, což s koncepcí VCS nijak nesouvisí.

Nikdo netvrdí, že co LInus dělá dělá automaticky dobře, ale když vy si myslíte, že co Linus dělá, dělá automaticky špatně, je dobré to do komentáře jako důvod proč odmítáte GIT napsat, aby si ostatní zbytečně nemysleli, že máte nějaké technické argumenty, a snažili se o tom s vámi diskutovat.

[MJ]

Je docela legrační, jak si v této pohnuté době mnozí lidé vykládají multiplatformnost jako "Chodí na Linux i na Windows"

Ostatně, GIT pod Cygwinem už běhá pěkně dlouho. Sice daleko pomaleji než na Linuxu, ale ještě pořád daleko rychleji než většina ostatních VCS.

Jinak Linus sice první verzi napsal za pár dní, ale poté, co o správě verzí pár let přemýšlel. Třeba SVN vypadá přesně opačně – někdo pár dní přemýšlel a pak se to pár let snažil naprogramovat

[finc]

Mel bych dotaz k tomu Mantisu:

Jak je na tom z podporou cestiny?

Je jednodussi ci prehlednejsi nez Bugzilla? Jde mi o to, ze bych potreboval neco, ehm, pro lidi, kteri se PC spise boji :)

Kdyz jsem zkousel Bugzillu, prijde mi dobra, az na to, ze je silene neprehledna. Vzdy mi trva nekolik minut, nez najdu pozadovanou vlastnost. Nevim, jak by se na to tvarili lide, od kterych potrebuji reportovat bugy, nove featury, atd.

[Luk]

Jak je na tom z podporou cestiny?

Docela dobře. Překlad není kdovíjak dokonalý, ale ujde to.

Je jednodussi ci prehlednejsi nez Bugzilla?

Jednodušší asi ne, má více funkcí. Ale přehlednější určitě a ovladatelnější bez diskuse. Kdyžtak tady je demo aktuální verze.

Nevim, jak by se na to tvarili lide, od kterych potrebuji reportovat bugy, nove featury, atd.

Já při každém pokusu použít Bugzillu přemýšlím, jestli patřím do Bohnic já nebo tvůrce Bugzilly.

[Filip Jirsák]

Já při každém pokusu použít Bugzillu přemýšlím, jestli patřím do Bohnic já nebo tvůrce Bugzilly.

To je jednoduché. Na začátku práce z Bugzillou mám vždycky pocit, že tam patří tvůrce Bugzilly. A když už začínám vážně pochybovat, jestli bych se tam neměl vydat sám, radši práci s Bugzillou ukončím…

[Michal Kašpar]

Co všichni proti té Bugzille máte. Pominu-li kapku nepřehledně udělané GUI formulářů (konkrétně rozlezlost prvků aby se nevešly na jednu obrazovku a nedostatečnost velikost některých), které se dá kompletně změnit (skin i šablona), tak máte ještě nějaké výhrady?

Opravdu by mě to zajímalo, protože ji potřebuji také nasadit a jsem v situaci, kdy lze ještě lecos změnit.

Mě osobně na ní u komunitních projektů vadí, že se musím všude registrovat, ale pak už se mi s ní pracuje poměrně dobře.

[Filip Jirsák]

Konkrétně já mám neustále problémy s tím, že nikdy nevím, jaké akce se po odeslání formuláře provedou. Chci přidat komentář, a mám pocit, že se tím zároveň změní stav chyby. Chci změnit stav chyby, a mám pocit, že k tomu musím poslat patch s komentářem (úplně takhle asi ne, ale něco podobného). Chci vyhledat chybu, a to samé políčko jednou slouží k hledání dle textu nebo dle čísla chyby, podruhé jenom podle čísla chyby. Myslím, že by měla být jedna chyba označena jako závislá na druhé, ale nevím, jestli to můžu nějak udělat, nebo na to nemám práva, nebo to mám napsat jako komentář. Odešlu komentář, a objevím se na stránce s úplně jinou chybou. A tak dále.

Kdybych Bugzillu používal denně (jako vývojář nebo tester), asi bych s tím problémy neměl. Ale protože ji používám jenom občas jako uživatel k hlášení chyb, potřeboval bych, aby ovládání Bugzilly odpovídalo tomu, jak s chybou zacházím jako uživatel – chci přidat komentář, tak mám formulář jenom pro text komentáře a jeho odeslání, a když ho odešlu, objeví se mi stránka chyby s mým komentářem. GUI Bugzilly a její workflow je asi dělané podle toho, jak s chybami interně pracuje Bugzilla, ale pokud tohle neznám, je pro mne její ovládání dost matoucí.

[Michal Kašpar]

Díky moc za odpověď, určitě se na tyhle věci ještě podívám.

Většina těch věcí je buď otázka nastavení (ten přesun na jinou chybu po zadání komentáře) nebo práv pro práci s chybou (pokud na to nemáte práva, tak to políčko nemůžete editovat, takže pokud se vám zdá, že to můžete změnit, tak také můžete) a u open source věcí mají často i běžní uživatelé poměrně široce nastavená práva.

To, že mohu v jednom kroku změnit víc věcí najednou (vždy se uloží vše, co jste v tom formuláři změnil) mi poměrně vyhovuje. Měl jsem tu čest pracovat s pár BTS, kde to bylo oddělené a připadalo mi to příšerně svazující a obzvlášť na pomalých linkách celkem frustrující (musel jste projít více formuláři). Ale chápu, že tohle nemusí každému vyhovovat.

[Filip Jirsák]

Já předpokládám, že Bugzilla má nějakou logiku, jak se s ní pracuje, bohužel tahle logika není (aspoň pro mne) zřejmá. Já třeba nemám nic proti tomu, aby bylo možné změnit víc věcí najednou – vadí mi to, že si dopředu nikdy nejsem jist, co se vlastně stane. Pak se to dál kumuluje – pokud mám z Buzilly pocit, že je nepřehledná, neznamená pro mne neexistence nějakého prvku, že bych neměl dostatečná práva, ale přemýšlím, jestli to není tím, že ten prvek je někde jinde – jenom ho neumím najít. To vše vůbec nemusí souviset s tím, jak se s Bugzillou pracuje, to může způsobit klidně jenom něšťastné rozvržení formuláře, nebo to může být tím, že je možné Bugzillu nakonfigurovat pro různé způsoby chování, a já jsem tak při použití různých instancí Bugzilly získal dojem, že se to chová pokaždé jinak = nepředvídatelně. Takže možná je problém jenom v tom „pozlátku“ (jestli je tlačítko na začátku nebo na konci) – ale pokud s Bugzillou pracuje uživatel, který chce ohlásit jednu chybu, nebo přidat komentář, nemá čas ani náladu studovat, jak má Bugzillu používat, ale je potřeba, aby to zvládl intuitivně.

[David Watzke]

Používám SVN (Gentoo overlay), ale asi někdy přejdu na Git, jednak abych se s tím naučil a navíc si myslím, že Linus ví o čem mluví

[pavlix]

Používám Git k plné spokojenosti... dobrovolně už nikdy nepoužiju správu verzí závislou na serveru ála cvs/svn.

Na bugy některou z webových aplikací, líbí se mi Trac (má v sobě wiki, tickety a pár dalších hraček).