Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
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
Čím skôr, tým lepšie. Marš na CZ.NIC a stiahni knihu Pro Git - veľmi Ti pomôže.1) je nacase sa zamysliet nad Gitom?
Nie.2) drzat vsetko ako jeden projekt v Eclipse?
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ť.3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?
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.4) rozdelit to na jednotlive projekty a mat zvlast repozitare?
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?
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é.
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.
Tiskni Sdílej: