Dětem začala škola a nedobrovolně se tak musí vzdělávat. Avšak pro dospělé, kteří se chtějí vzdělávat nebo naopak se o vědomosti podělit, je tu Virtuální Bastlírna - jako každý měsíc si můžete online a zdarma nezávazně popovídat o vědě a technice nejen s bastlíři, ale i s vývojáři, vědci nebo profesory. A čemu se strahováci budou věnovat? Blíží se KiCAD 11 s nespočtem novinek, z nichž zde musí zmínit alespoň možnost kótování a závislostí z
… více »Asahi Linux, tj. Linux pro Apple Silicon, oficiálně podporuje čipy M3 (M3, M3 Pro a M3 Max).
Společnost Acer oslavila 50 let. Na tiskové konferenci next@acer představila řadu novinek. Vypíchnout lze přenosný ePaper displej Acer EP130K, přenosné řešení se třemi displeji Acer PD163Q P3 nebo herní handheld a notebook v jednom DualPlay Mini.
Server SiFive BigSky SF-2U870 2U je založený na jádře SiFive P870-D, zatím je naintegrovaných 32 jader 256 GB RAM 2 GHz, škálovat lze do 256 jader na čip. O něco podrobnější popis serveru v článku SiFive BigSky Ships the First RISC-V Server. Is the GPU Head Node the Prize? na futurumgroup.com. Asi ani tento čip nebude na úrovni nejlepších 64-bit ARMů a AMD Zenů, ale splňuje RVA23 specifikaci a je podporovaný Ubuntu 26.04 LTS a RHEL 10. V článku je
… více »Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
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