Bun (Wikipedie), tj. běhové prostředí (runtime) a toolkit pro JavaScript a TypeScript, alternativa k Node.js a Deno, byl vydán ve verzi 1.3. Představení novinek také na YouTube. Bun je naprogramován v programovacím jazyce Zig.
V Lucemburku byly oznámeny výsledky posledního kola výzev na evropské továrny pro umělou inteligenci neboli AI Factories. Mezi úspěšné žadatele patří i Česká republika, potažmo konsorcium šesti partnerů vedené VŠB – Technickou univerzitou Ostrava. V rámci Czech AI Factory (CZAI), jak se česká AI továrna jmenuje, bude pořízen velmi výkonný superpočítač pro AI výpočty a vznikne balíček služeb poskytovaný odborníky konsorcia. Obojí bude sloužit malým a středním podnikům, průmyslu i institucím veřejného a výzkumného sektoru.
Byla vydána (𝕏) zářijová aktualizace aneb nová verze 1.105 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.105 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Ve Firefoxu bude lepší správa profilů (oddělené nastavení domovské stránky, nastavení lišt, instalace rozšíření, uložení hesla, přidání záložky atd.). Nový grafický správce profilů bude postupně zaváděn od 14.října.
Canonical vydal (email) Ubuntu 25.10 Questing Quokka. Přehled novinek v poznámkách k vydání. Jedná se o průběžné vydání s podporou 9 měsíců, tj. do července 2026.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzi 1.5.0.
Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
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