abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 16
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: zaciatok projektu: na zelenej luke

25.7. 18:31 exoskeleton
zaciatok projektu: na zelenej luke
Přečteno: 682×

dobry den,

sme mala developerska firmicka (3 ludia) a robime mobilne aplikacie. ako verzovaci nastroj pouzivame SVN. IDE Eclipse. Pre kazdu zakazku/projekt mame zvlast repozitar.

Dostali sme sa ku vacsiemu projektu ktory bude mat backend (asi tomcat), frontend (web), GUI (client). Client bude mat moznost pouzivat pluginy. Rad by som sa opytal aky zvolit model vyvoja a verzovania?

1) je nacase sa zamysliet nad Gitom?

2) drzat vsetko ako jeden projekt v Eclipse?

3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?

4) rozdelit to na jednotlive projekty a mat zvlast repozitare?

dakujem

Odpovědi

26.7. 03:03 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
  1. Git bych doporučil pro cokoliv. V „nejhorším“ lze použít git-svn a server mít stále na SVN, ale pokud se naučíte s Gitem pracovat (a poznáte i webové nástroje jako GitLab), už se k SVN nebudete chtít vracet.
  2. Určitě ne. Jsou to tři oddělené části, měly by mít (nejméně) tři Eclipse projekty. (Ale mohou být v jednou workspace; doporučuji workspace per repozitář, takže záleží na rozdělení dále.)
  3. Větve podle projektů nedělejte, Git to nepotřebuje a dost to zhoršuje synchronizaci mezi projekty. Doporučil bych nastudovat Git-flow, které docela dobře vysvětluje, k čemu větve slouží, a doporučuje jeden způsob, jak je používat.
  4. Jestli mít každý projekt jako samostatný repozitář nebo to mít v jednom, záleží hodně na tom, jak moc budou na sobě jednotlivé části záviset. Obecně bych dal dohromady backend+frontend (API mezi nimi asi nebude úplně stabilní, takže je vhodné držet dohromady odpovídající verze) a oddělil klienta (API by mělo být stabilní, jinak to zákazníkům rozbijete, takže to není vázané na konkrétní verzi serveru), ale i všechno dohromady by pro Git nebyl žádný problém.
AraxoN avatar 26.7. 19:53 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke

1) je nacase sa zamysliet nad Gitom?

Čím skôr, tým lepšie. Marš na CZ.NIC a stiahni knihu Pro Git - veľmi Ti pomôže.

2) drzat vsetko ako jeden projekt v Eclipse?

Nie.

3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?

Nie, branče slúžia na niečo úplne iné. Až prejdeš na Git tak to pochopíš. SVN Ti túto vedomosť nemal ako sprostredkovať.

4) rozdelit to na jednotlive projekty a mat zvlast repozitare?

Jeden repozitár nie je pre Git problém, ale SVN z toho dostane záhul (moja skúsenosť). Ak ale máš podprojekty, ktoré spolu súvisia len cez API, asi by som ich aj tak oddelil do samostatných repozitárov.
A fine is a tax for doing wrong. A tax is a fine for doing well.
28.7. 12:52 exoskeleton
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
rozhodli sme sa pre model projekt per repozitar. pricom budeme mat samostane projekty pre backend, frontend, klient, pluginy. a vsetko to bude v jednom Eclipse workspace pre lepsiu orientaciu.

budeme sa chvilu hrat s gitom a uvidime ci premigrovat vsetky doterajsie projekty alebo nie, predsa len drzat 2 verzovacie systemy pre malu firmicku je overkill.

dakujem za rady aj za tip na knihu o Gite v zrozumitelnom jazyku :).

28.7. 15:22 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Doporučuji mít workspace per repozitář, hodně to zjednodušuje správu nastavení pro ten workspace. Pokud vám víc vyhovuje mít všechno v jednom workspace, bude lepší to mít i v jednom repozitáři, problémy s konflikty při práci různých lidí na různých částech v Gitu na rozdíl od SVN nejsou (z podstaty distribuovaného VCS). Rozdělit existující repozitář je v případě potřeby docela snadné, sloučit rozdělené repozitáře je hodně těžké. (Stejně jsme postupovali i u nás, když se přecházelo ze SVN na Git, každá část měla svůj repozitář. O dva roky později jsme to pracně slučovali, protože se s tím pracovalo hrozně blbě, závislosti to při přepínání větví neustále rozbíjely a webové nástroje si s tím nedokázaly poradit.)
28.7. 17:06 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
"workspace per repozitář" - OK, nemám námitek.

Co se myslí tím rozbíjením závislostí při přepínání větví? Rozhrani mezi moduly by mělo být neměnné, resp. může se pouze rozšiřovat.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
28.7. 20:23 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Co se myslí tím rozbíjením závislostí při přepínání větví?

Pokud budete mít podprojekty v samostatných repozitářích, bude těžké udržet přehled o tom, který snapshot podprojektu A je kompatibilní s kterým snapshotem podprojektu B. Pro posloupnost klasických release verzí se to ještě asi uhlídat dá, ale třeba při bisectu, kdy potřebujete přeložit a otestovat zcela obecné snapshoty, si to moc představit neumím.

Rozhrani mezi moduly by mělo být neměnné

To je chvályhodné předsevzetí, ale… Pane Smrtko, proč vy se pořád tak usmíváte?

28.7. 20:59 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Tak snad se v každém projektu uvádí, kterou minimální verzi jiného podprojektu vyžaduje. Také existují anotace "deprecated" a podobné mechanismy.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
28.7. 21:10 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Jak jsem už napsal, dokud se můžeme bavit o nějakém omezeném počtu verzí, tak to ještě jde. Tady se ale bavíme o gitu a jednotlivých commitech, kterých může být spousta a které ani nejsou lineárně uspořádané.
28.7. 21:19 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
V Gitu existují také nějaké větve, z nichž většina do produkce prostě nejde. Kombinovat nějaké větve typu develop nebo dokonce feature prostě nemá význam.

Gitflow
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
28.7. 21:27 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
V SVN je to jednoduché, revize rostou lineárně, takže pokud máte revizi 172 a podprojekt má napsáno, že vyžaduje 154+, tak by to mělo fungovat. Git ale nemá lineární historii, takže se nemůže číslovat lineárně, a pokud řeknete, že podprojekt vyžaduje commit aa725d4, tak není na první pohled jasné, jestli commit 57adf45 je jeho potomek (vyhovuje) nebo je to předek nebo třeba bratranec (nevyhovuje). Dá se to udržovat, ale je s tím spousta práce, a pokud nemáte silný důvod to rozdělovat hned na začátku (budete vyvíjet víc klientů, klient bude open source ap.), nerozděloval bych to. Rozdělit se to dá později.
28.7. 21:41 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
K tomuto účelu se používají tagy.

Aby nedošlo k mýlce: Nevidím důvod, proč by se měl projekt uměle rozdělovat v místech, kde by mohla vzniknout silná závislost mezi moduly, ale spíš tam, kde by si různé týmy vývojářů mohly vzájemně lézt do zelí.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
28.7. 21:15 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Poměrně často se nám stávalo, že při přepínání z master na různé release větve vývojář zapomněl přepnout všechny repozitáře, což pak mohlo mít za následek nefungující prostředí. Odhalí se to rychle, ale až po zkompilování a spuštění všeho, a to nějaký čas zabere, a je otravné na to muset pořád myslet (takže jsme pro to měli skript, který ale třeba při nekomitnutých změnách na některých repozitářích selhal a nastal stejný problém). Pak to dost ovlivňovalo CI server, někdo založil novou release větev, ale zapomněl nastavit všechny repozitáře, aby ji používaly, což nakonec může dostat do produkce i vadný produkt (Ci server otestuje místo nefunkčního releasu master, který projde). A takové věci jako merge/pull requesty jsou opravdu lahůdka, protože schvalující musí zkontrolovat změny ve všech repozitářích, než může změnu schválit. Pokud schválí změnu v jednom repozitáři, ale má potom výhradu ve druhém, klidně to může skončit ve stavu, kdy větev nefunguje. Nebo se může stát, že schválí změnu v jednom repozitáři, ale v dalším repozitáři mezitím někdo jiný schválí jinou změnu, dojde k merge conflictu, změna schválit nejde a zase je rozbitá větev.
28.7. 21:26 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Tak snad se vždy pracuje jen na kódu jednoho repozitáře, ne? Každý se kompiluje a testuje extra a každá změna se schvaluje také extra - nezávisle na ostatních repozitářích. Jinak to dělení do více repozitářů postrádá na významu.

Repozitáře prostě musí být na sobě zcela nezávislé.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
28.7. 21:43 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
To není tak jednoduché, pokud zavádíte nové vlastnosti. Znamená to zahodit agilní vývoj a vytvářet přesné specifikace, aby se vám nestalo, že v půlce vývoje, kdy už máte hotovou změnu na backendu, zjistíte, že na frontendu to vlastně takhle nemůže fungovat a rozhraní s backendem by mělo být jiné (v agilním vývoji to není problém, API se mění celou dobu, dokud není hotovo). A ano, v Gitu postrádá takové dělení smysl, v SVN je ale nezbytné, jinak si budou různí vývojáři blokovat práci, a tak spousta lidí přecházejících ze SVN do Gitu má tendence mít těch repozitářů co nejvíc.
28.7. 21:56 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Proto by rozhraní mělo být tenké, aby změna specifikace v jednom modulu neměla vliv na specifikaci v druhém modulu. Jinak to rozdělování nedává smysl a je lepší to nechat pohromadě.

Mezi dvěma commity by se také neměl modifikovat víc než jeden soubor a před commitem by měl projít testy.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
29.7. 00:21 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Proč by se neměl modifikovat víc než jeden soubor? Je normální, že se v jednom commitu modifikuje několik souborů, třeba v Javě interface a implementace, v C++ hlavičkový a zdrojový souboru, mnohdy i dokumentace, testy nebo Makefile. Větší commity v kernelu modifikují klidně i desítky souborů. Případné merge conflicty budou stejně naprosto totožné, protože Git každý soubor merguje samostatně.
29.7. 01:07 Kit | skóre: 36 | Brno
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Když změníš více souborů, tak se blbě píše komentář, co jsi vlastně modifikoval. Pokud commituješ jen jeden soubor, tak se mnohem snáze "cestuje časem".

Nejdříve změním interface a postupně všechny jeho implementace. Hezky po jednom.

Dokumentace se nachází ve stejném souboru jako zdroják, takže i když ho změníš současně se zrojákem, je to stále změna v jednom souboru.

Modifikace Makefile stojí za zcela samostatný commit. Moc často se nedělá a je dobré, když je v historii dobře vidět.

Napsal jsem "neměl by", nikoli "nesmí". V SVN mnozí commitují jen 1× denně, což je špatně. V Gitu když uděláš commit 3× za minutu, tak je to stále v pohodě.

Většinou totiž dělám na jednom souboru (např. třídě), dokud ho nemám hotový. Do ostatních souborů přitom (zpravidla) nezasahuji. To snižuje i počty merge konfliktů.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
29.7. 04:14 Sten
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
Proč by se psal blbě komentář, co jsem modifikoval? Přijde ti třeba, že se tenhle komentář musel blbě psát? Je to jedna změna ve čtyřech souborech.

Mě se mnohem lépe cestuje časem, když při tom nemusím procházet každý jeden krok, jak se ty párky vyráběly. Ono stejně není nijak zajímavé, jestli se po změně interface napřed měnila tahle konkrétní implementace nebo nějaká jiná.

git log --stat u každého commitu vypíše, jaké soubory se měnily. Psát to do komentáře je zbytečné.

Pokud chci vidět modifikace Makefile, tak stačí zavolat git log Makefile (případně git blame Makefile, pokud mě zajímá, kdo tam změnil konkrétní řádek).

Dokumentace není jen ve zdrojáku. Zdroják popisuje API, ale těžko bude popisovat třeba to, jak se daná aplikace instaluje a debuguje, s jakými formáty souborů pracuje či jak jsou zdrojáky organizované.
29.7. 07:09 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke

Takže radši budete mít v gitu polovinu commitů, které nejspíš nepůjdou ani přeložit, natož aby fungovaly? Happy bisecting… Nemluvě o tom, že ani samotné tvrzení, že se bude hůř psát commit message, mi nedává moc smyslu.

Promiňte mi mou upřímnost (a přímost), ale celá druhá část této diskuse na mne působí, jako kdybyste nikdy s žádným netriviálním projektem do kontaktu nepřišel, ale nejsa nezatížen praktickými zkušenostmi, vytyčil jste jakési teoretické zásady a teď na nich lpíte, přestože lidé, kteří praktické zkušenosti mají, se vám snaží vysvětlit, že nejsou moc v souladu s tím, jak takový vývoj v praxi funguje.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.