Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
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