Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
vývoj na mainu udělat větev a nasadit ji na produkční vývoj na mainu a opravy chyb na větvi merge oprav z větve do mainu vývoj na mainu a opravy chyb na větvi merge větve do mainu udělat větev a nasadit ji na produkční atd...Merge jsme dělali pomocí tagování v místě vytvoření větve a po každém merge, takže následující merge se dělal od posledního mergepointu do aktuálního stavu. Doufal jsem, že nám svn práci usnadní a bez tagů se obejdeme, ale podle dokumentace to není pro svn přirozený postup - předpokládá merge z trunku do větví, merge zpět pouze pomocí --reintegrate, což ale větev pro další merge zničí. Může mi, prosím, někdo poradit jak na to?
ale taky už mlčim
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
22.4.2011 12:10
svn mergeinfo --show-revs eligible urlvětve
a mergováním jednotlivých spojitých úseků revizí do pracovní kopie - ostatní možnosti házely děsivé konflikty. Je-li nějaký lepší postup, rád se poučím.
) a protože se potřebujeme soustředit na vývoj a ne na verzování. Náš způsob práce nevyžaduje distribuované úložiště a náš projekt nevyžaduje změnu způsobu práce. O verzovací systémy se zajímám asi jen já, protože já řeším vytváření a nasazování verzí, ostatní si prostě upnou, odbudou si své programování, skouknou diff, commitnou a dál je to nezajímá - kdo by řešil co kam pushnout.
Náš způsob práce nevyžaduje distribuované úložiště a náš projekt nevyžaduje změnu způsobu práce.No nevím - ten způsob práce je zřejmě založen na větvích a jejich mergování, což v SVN není moc praktické. Takže aby to nakonec neznamenalo změnu způsobu práce...
Protože o tom nerozhoduju já (nevěřil byste, kolik práce dalo prosadit svnA vy byste nevěřil, jak moc ta práce byla
O verzovací systémy se zajímám asi jen já, protože já řeším vytváření a nasazování verzí, ostatní si prostě upnou, odbudou si své programování, skouknou diff, commitnou a dál je to nezajímá - kdo by řešil co kam pushnout.Ono to chce vést vývoj trošku pečlivěji a rozhodování dělat na základě nějakých informací a s rozmyslem... ale jestli nemáte možnost toto dostatečně ovlivnit, nezbývá mi, než s vámi soucítit.
O verzovací systémy se zajímám asi jen já, protože já řeším vytváření a nasazování verzí, ostatní si prostě upnou, odbudou si své programování, skouknou diff, commitnou a dál je to nezajímáZatím kdykoli jsem s někým strávil nad Gitem trochu větší čas, tak jsem ho přesvědčil, že je na správu a používání jednodušší než subversion. A zároveň poskytuje širší možnosti. Tudíž zvolit za verzovací systém v roce 2011 SVN oproti Gitu znamená zvolit komplikovanější a zároveň slabší řešení.
kdo by řešil co kam pushnout.Jestli to dobře chápu, tak o vydávání verzí se staráte vy, takže byste to řešil pouze vy. Ostatní by neřešili kam pushnout. Pokud chcete alespoň zhruba zachovat způsob práce, tak všichni vývojáři dávají jenom push a neřeší kam. Prostě... udělají samostatnou úpravu, otestují, commitují (lokálně), udělají další úpravu, otestují, commitují... pak ty změny všechny najednou pošlou (push). Jediný rozdíl je v tom, že balíky změn se připravují lokálně, takže se nestává, že by vznikal velký sprasený commit kvůli tomu, že se zrovna domluvilo, že se nesmí nějakou chvíli commitovat. A taky se nestává, že by se zastavil vývoj, když na hoďku vypadne server nebo se překopává síť. Navíc... Subversion neumí větve ani tagy. Tvrdit, že je umí, je jako tvrdit, že příkaz cp umí verzovat. Samozřejmě, že jde k tomu použít (například nakopíruju adresář a dám mu jako příponu datum a čas), ale není to plnohodnotný nástroj. CVS jsem naštěstí nepoužíval a Subversion jsem používal aktivně a krátce, a bylo pro mě zklamáním, že mi například nefungoval offline (udělat více změn adresářové struktury bez konektivity). Pak jsem přecházel na Git, mimo něj lze ještě doporučit Mercurial a možná někdo něco přidá. Mercurial by měl být na používání ještě jednodušší než Git, ale detaily neznám. Kdyby něco, klidně napište na mail.
Já jo, a to jen pro sebe, Subversion byl velký krok, a to jen pro vlastní potřebu, dál jsem se zatím nepropracoval (dle: „když to funguje a nic tě netrápí nerýpej do toho“).Jasně, pro vlastní potřebu se v SVN udělá lokální repozitář a je vystaráno. Ale dostat ho na server je strašně těžký. V Gitu uděláš lokální repozitář, a automaticky je z něj i vzdálený repozitíř po SSH. A ani donastavit další protokol není těžké.
CVS −> Subversion to byl stejný skok jako ze ZIP-ovaných „přírustkových záloh“ na CVSTak vzhledem k tomu, že Git umí skutečné větve, tagy a podobné věci, a je „zadarmo“ decentralizovaný, tedy pro repo-to-repo akce není potřeba nijak přiohýbat, naopak jsou standardním způsobem práce... tak od SVN ke Gitu to je z hlediska funkcionality asi podobný skok.
asi to nebude 0 minut je třeba něco nainstalovat a tak. A zprovoznit něco s čím nevím co mám dělat mi taky moc nepomůže - je lepší to trochu umět
asi to nebude 0 minut je třeba něco nainstalovat a tak.Zaokrouhlil jsem na celé minuty :).
$ sudo yum install git $ git init muj-projektAle máš pravdu, netřeba se přít. Já jsem vycházel z reálných (ale svých osobních) zkušeností, kdy jsem někdy před pár lety měl za úkol zprovoznit Subversion a musel jsem se prát se spojením apache, mod_dav a dál, protože to byl jediný způsob, co nám tehdy vyšel jako rozumný. Git od začátku vývojářům nasazuju přes SSH.
…. Ale jinak mlcim taky, a to znamena souhlas.
Nerikal jsi, ze budes uz mlcet?Právě, že jsem říkal, že mlčím :), a v tu chvíli jsem měl ještě pravdu :D. Ale pak jsem to nevydržel, takže nemlčím, a pravdu mám vlastně taky (na propagaci decentralizovaných SCM není co pokazit).
Vzhledem k tvému aktivnímu přístupu bych v tom neviděl problém.
Ale možná jde o komunitní projekt.
myšlenka, že bych kvůli verzovacímu systému měl měnit zaměstnání mi připadá absurdníVelké části místních čtenářů přijde absurdní, že by při výběru práce nezohledili co a jak se tam dělá. Je to dáno i tím, že šikovný člověk v tomhle oboru si může vybírat.
když jsem nastupoval, zajímal jsem se o zhruba tyhle věci (seřazeno víceméně dle důležitosti: perspektiva firmy, mé povinnosti ve firmě, umístění firmy (dojíždění), platové hodnocení, programovací jazyk, vybavení a organizace pracovních prostor a operační systém mé pracovní stanice - používaný verzovací systém jsem opravdu neřešilTak já třeba před časem vybíral podle toho, kdo tomu šéfuje... a pak jakýkoli můj dobrý nápad, který zapadal do budoucích plánů, byl vzápětí implementován. Takže... taky jsem určitě nevybíral podle VCS, to je blbost, ale vybíral jsem podle flexibility vedení, nebo spíš... nepotřeboval jsem nutně vydělávat, vzal jsem práci jen pokud mě bavila. No a postupem času to tak nějak vykrystalizuje.
nevěřil byste, kolik práce dalo prosadit svnPřesně tak, mám zkušenost, že lidé, co fungují na CVS, nejsou duševně připraveni na přechod kamkoliv jinam, a SVN je v tomto případě "nejmenší zlo". CVS totiž trpí syndromem nepřiměřené složitosti - je tak nepoužitelné, že za tu dobu co s ním uživatelé pracují, si vytvořili spoustu obezliček a vlastních postupů jak s ním pracovat. Přechod pro ně znamená vše zahodit a začít od znova. Domnívají se, že to znamená projít si celým postupem vybudování si obezliček a postupů nanovo. Nejsou ochotni přijmout že nějaký jiný systém (např. git) všechny ty věci umí sám od sebe.
psát checkout a commit mě na gitu vytáčí).git umí aliasy :)
Tiskni
Sdílej:
22.4.2011 23:12