Administrace komentářů

Pokud se má vývoj pohnout dopředu, zak to holt bude muset projít tímto stavem.

Už se v tom zas ztrácím, ale jsem si jistý, že vývoj dopředu nevede přes chybovou hlášku místo košíku, rozhodně ne mimo lokální PC vývojáře

A nebo si programátor s autorem šablony domluví rozhraní mimo VCS (proč?), pak se upraví šablona, aby fungovala s oběma verzemi (práce navíc), pak se změní logika a na závěr se změní šablona na definitivní variantu.

Tomuhle taky nerozumím, ale mimo VCS jít nic nemusí. Pokud funguje aplikační logika nového košíku, tak se na něj může udělat webová tvář, aniž by to ovlivňovalo starý košík. Pokud to stihnete za jeden den, tak to můžete vyměnit, pokud je to na dýl tak to musíte měnit per partes. Pak budete mít po jistou dobu kombinaci nového a starého košíku, fungovat ale bude vše.

Zkuste dát nějaký příklad, kde se má něco změnit, a vznikne problém, ale ten problém není chybová hláška v trunku, protože to už jsme vyčerpali.

To bude prima práce, když každou změnu v kódu vzápětí někdo revertne.

To asi není moc prima když je každá změna v kódu tak špatná že nezbejvá než ji revertovat.

Změnila by se podstatně. Ty dva týdny ve větvi by se pracovalo na odstranění té chyby, a do hlavní větve by se přetáhl až opravený, odladěný a otestovaný kód.

To skoro zní jako byste předpokládal, že když si nevšimnu chybu před commitem do trunku, tak si ji zaručeně všimnu před commitem do větve. Mnohem pravděpodobnější je, že si tu chybu nikdo nevšimne, až dokud se větev nebude zavírat.

Větší pohoda je, když můžu na nějaké funkci dělat do té doby, než ji považuji za hotovou, a netiká mi budík, že ji musím comitnout do hodiny za každou cenu.

No tak vám tiká budík na 2 týdny. Odhad práce na 2 týdny bude z definice méně přesný než odhad práce na několik hodin. Proto se ty věci sekají po hodinách a ne týdnech.

Nebo vám netiká budík a pak to bude možná zejtra a možná za rok. Takhle se dá pracovat při opravě chyby v KDE, ne při zaměstnání.

Ve verzi N někdo comitnul změnu s chybou, vzápětí jiný comitne verzi N+1 s kódem, na který mám navázat. Pak se zjistí, že v N je chyba, udělá se revert na verzi N-1 – a když to dobře půjde, může autor verze N+1 své změny comitnou podruhé.

Ve všech normálních VCS jde oddělat commit N tak, aby tam N+1 zůstal.

To by mne zajímalo, jak ty komplet testy (včetně manuálních) zvládáte během toho půl dne, co máte na vývoj. Abyste stihl udělat změnu, zmergovat ji, udělat komplet testy a takhle ověřený kód vnutit ostatním.

Naplánuju si množství změn tak, abych to za tu dobu měl. Já nevím, ale za půl dne se dá napsat spousta kódu. Spousta věcí netrvá ani tolik. A jiné zas trvají celý den, ale rozhodně ne týden.

Samozřejmě že za tu dobu nemusí být něco funkčně hotové, ale je to hotové technicky, a to třeba do té míry, že zítra si to může stáhnout někdo jiný a pokračovat. Viz třeba ta výměna databáze. Jak dlouho Vám trvá upravit skript kterej balí RPMko, aby do něj přibalil dalších 5 souborů, a ověřit že to dělá? A jak dlouho pak trvá napsat skript kterej spustí databázi jako službu? Je to každé snad práce na týden? Takže asi tak.