Společnost Apple slaví padesáté narozeniny. Založena byla 1. dubna 1976.
FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.24.0. Toto velké opravné vydání implementuje SABR (Server-Based Adaptive Bit Rate), což řeší část nedávných problémů s načítáním videí z YouTube, a aktualizuje základní komponenty jako Electron nebo přehrávač Shaka Player.
Je tu opět apríl. O víkendu zmizel kamion s 12 tunami tyčinek KitKat. Firmy to využívají k aprílovým žertům. Groupon má super akci. Koupíte 1 tyčinku a dostanete 100 zdarma. Ryanair si přelepil letadla. Šéf Outlooku se ptá, proč mají v baráku 14 beden tyčinek KitKat (𝕏). Prusa Research představuje Prusa Pro ACU a vysvětluje proč přílišné sušení škodí vaším filamentům. Telefon Sony Xperia má miliónnásobný zoom (𝕏). PC.net představil Super Ultrabox 2600 se zajímavými parametry. Další aprílové novinky například na April Fools' Day On The Web.
Společnost OpenAI, která stojí za chatovacím robotem s umělou inteligencí (AI) ChatGPT, získala od investorů 122 miliard USD (2,6 bilionu Kč). Hodnota společnosti tak dosáhla 852 miliard dolarů (více než 18 bilionů Kč). Nejnovější kolo investování se stalo největší, jaké zatím firma uskutečnila, a peníze mají posílit ambiciózní plány rozšíření výpočetní kapacity, datových center a nábor talentů.
Nástroj k identifikaci občanů v on-line komunikaci s úřady byl dnes dopoledne zhruba dvě hodiny částečně nedostupný. Problém se objevil kolem 09:00 a podařilo se ho vyřešit kolem 11:00. Částečně nedostupná byla služba Národní identitní autority (NIA), problémy podle DIA (Digitální a informační agentura) ovlivňovaly přihlašování například i přes bankovní identitu. „Dostupnost NIA byla plně obnovena, přihlášení k digitálním službám
… více »Eben Upton oznámil další zdražení počítačů Raspberry Pi kvůli růstu cen pamětí a představil Raspberry Pi 4 s 3 GB RAM za 83,75 dolarů.
Anthropic patrně omylem zveřejnil celý zdrojový kód svého CLI nástroje Claude Code prostřednictvím přiloženého sourcemap souboru v npm balíčku. Únik odhalil doposud nijak nezveřejněné funkce jako je například režim v utajení, autonomní agent 'KAIROS', orchestrace multi‑agentů, režim snění nebo dokonce virtuální mazlíček Buddy. Zajímavostí je detekce naštvání uživatele pomocí obyčejného regexpu. Anthropic rychle odstranil sourcemap a vydal opravu, nicméně kopie kódu se již stihly na GitHubu rozšířit mezi prostým lidem.
Copilot automaticky vkládal do pull requestů 'propagační tipy', reklamní text se na GitHubu objevil ve více než jedenácti tisících pull requestech. Po vlně kritiky byla tato funkce zablokována a produktový manažer Tim Rogers připustil, že umožnit Copilotovi upravovat cizí pull requesty bez vědomí autorů byla chyba.
Je 31. března a tedy Světový den zálohování (World Backup Day). Co by se stalo, kdyby Vám právě teď odešel počítač, tablet nebo telefon, který používáte?
Digitální a informační agentura (DIA) přistupuje ke změně formátu důvěryhodného seznamu České republiky z verze TLv5 na verzi TLv6, která nastane 29. dubna 2026 v 00:00 (CET). Ke změně formátu důvěryhodných seznamů členských států (tzv. Trusted Lists) dochází na základě změn příslušné unijní legislativy. Důvěryhodné seznamy se používají v rámci informačních systémů a aplikací zejména pro účely ověřování platnosti elektronických
… více »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