Společnost Backblaze zveřejnila statistiky spolehlivosti pevných disků používaných ve svých datových centrech za rok 2024. Ke konci roku 2024 vlastnila 305 180 pevných disků. Průměrná AFR (Annualized Failure Rate), tj. pravděpodobnost, že disk během roku selže, byla 1,57 %. V roce 2023 to bylo 1,70 %. V roce 2022 to bylo 1,37 %.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250211 mikrokódů pro své procesory řešící 5 bezpečnostních chyb.
Byla vydána nová verze 1.24 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Jiří Eischmann upozorňuje, že GNOME nemá české překladatele: "Posledních minimálně 15 let byly překlady GNOME do češtiny ve výborném stavu. U každého vydání jsem jen hlásil, že je vše přeložené, poslední roky to platilo i pro drtivou většinu dokumentace. Poslední rok se to ale začalo zadrhávat. Přispěvatelé, kteří to dlouhé roky táhli, odešli a není nikdo, kdo by to po nich převzal. Proto jsme se rozhodli jít s pravdou ven: GNOME momentálně nemá české překladatele a pokud se toho neujme někdo nový, překlady začnou postupně upadat."
Otevřený zvukový bezztrátový kodek FLAC (Free Lossless Audio Codec, Wikipedie) byl vydán v nové verzi 1.5.0. Hlavní novinkou je podpora vícevláknového kódování. V prosinci loňského roku byl FLAC formálně specifikován v RFC 9639.
Evropská unie hodlá iniciovat investice do rozvoje umělé inteligence v hodnotě 200 miliard eur, v přepočtu zhruba pět bilionů korun. V projevu na summitu o umělé inteligenci v Paříži to v úterý řekla předsedkyně Evropské komise Ursula von der Leyenová. Umělá inteligence podle ní může přispět mimo jiné ke zvýšení konkurenceschopnosti.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.3 (Mastodon). Přehled novinek i s videi a se snímky obrazovky v oficiálním oznámení. Podrobný přehled v seznamu změn.
Lennart Poettering se na Mastodonu rozepsal o novince v systemd, na které pracuje: systemd bude umět nabootovat z obrazu disku staženého pomocí HTTP v rámci initrd.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2025.2. Nově lze zálohovat také na Google Drive a Microsoft OneDrive.
V kinech aktuálně běží animovaný film Kočičí odysea, v originálu Flow, (Wikipedie) vytvořený v Blenderu. Film získal řadu ocenění a má dvě nominace na Oscary 2025. Na ČSFD má 80 %. Režisérem je Gints Zilbalodis. Rozhovor s režisérem na stránkách Blenderu.
Systémy pro správu verzí (VCS) nejsou v oboru softwarového inženýrství žádnou novinkou.
Už na přelomu 70. a 80. let se používalo SCCS pocházející z Bellových laboratoří,
na které navázalo GNU RCS,
jehož autorem je Walter F. Tichy z Purdue University.
Později si vývojáři oblíbili CVS,
jehož historie sahá do června 1986, kdy Dick Grune poslal do diskusní skupiny comp.sources.unix
sadu shellových skriptů.
Ačkoliv CVS v aktuální verzi tyto zdrojové kódy neobsahuje, používá z nich některé algoritmy.
V roce 1989 Brian Berliner navrhl a napsal systém CVS a později se k němu připojil Jeff Polk.
Začátkem 21. století se rozšířil zejména systém Subversion (SVN). Počátky jeho historie sahají do roku 2000, kdy firma CollabNet začala shánět vývojáře pro komponentu svého produktu CEE týkající se správy verzí. CollabNet Enterprise Edition (CEE) dříve využíval systém CVS. Ten se firma rozhodla nahradit a vyvinula tak zcela nový program – Subversion. Kontaktovali CVS konsultanta a autora knihy Open Source Development with CVS Karla Fogela a jeho kamaráda Jim Blandyho, kteří souhlasili se spoluprací na projektu. Dále se zapojili Ben Collins-Sussman, Brian Behlendorf, Jason Robbins a Greg Stein. V květnu roku 2000 začala detailní analýza a po čtrnácti měsících implementace (31. srpna 2001) se stal Subversion použitelným a vývojáři mu svěřili správu zdrojových kódů samotného Subversionu místo CVS. Což můžeme považovat za důkaz dospělosti systému, podobně jako u kompilátorů, které jsou kompilovány samy sebou.
Zatímco se Subversion šíří do praxe a nahrazuje v té době už mírně zastaralé CVS, začíná se pracovat na nových verzovacích systémech s jinou architekturou. Jsou to decentralizované verzovací systémy jako GNU arch (2001), Darcs (2002) a Monotone (2003). V roce 2005 se objevují Git, Mercurial a Bazaar. A o rok později pak Fossil – ten sice nepatří k nejpoužívanějším, ale možná nás zaujme integrovanou wiki a systémem na správu požadavků/chyb.
Někteří autoři jako Joel Spolsky dokonce považují distribuované verzovací systémy za největší pokrok v technologiích pro vývoj softwaru. Ať už jim dáme za pravdu, nebo ne, jedno je jisté – každá další generace verzovacích systémů přináší zajímavé myšlenky, posouvá hranice výkonu, kapacit a úspornosti, nebo přichází s novou koncepcí. Je poučné sledovat historii a zábavné těšit se na budoucnost. Co nás asi čeká během příštích pár let? Můj osobní tip je jednak čím dál tím větší integrace s dalšími vývojářskými nástroji (správa chyb, testování, projektové řízení…) a jednak větší uplatnění verzovacích systémů i mimo oblast softwarového inženýrství.
Verzovací systém je v dnešní době nepostradatelným pomocníkem snad pro každého vývojáře. Slouží jako úložiště zdrojových kódů a dalších důležitých souborů, uchovává jejich historii (verze) a umožňuje spolupráci s ostatními vývojáři. Uveďme si alespoň pro pořádek, jaké jsou hlavní výhody používání takového systému:
Následující obrázek znázorňuje typické uspořádání – máme společný server, na který jednotliví členové týmu odesílají svoje upravené soubory a stahují si změny, které provedli jejich kolegové. Server je jen jeden a pracovní kopii má každý člen týmu vlastní:
Při postoupení (commit) sady změn (changeset) do společného úložiště vzniká verze – je dobrým zvykem ke každé verzi napsat výstižný textový popis, aby ostatní věděli, v čem změna spočívá, aniž by museli procházet jednotlivé zdrojové kódy.
U centralizovaných systémů máme kompletní historii změn jen na serveru zatímco na klientech bývá jen poslední verze a rozpracované soubory. Také zde máme jasně rozdělené role – server (společné centrum) a klienti (na počítačích jednotlivých vývojářů).
V případě distribuovaných (decentralizovaných) systémů jsou všechny uzly rovnocenné – na všech máme kompletní historii a můžeme se vrátit k libovolné verzi, aniž bychom se museli dotazovat nějakého serveru. Role nejsou pevně dané, můžou se dynamicky měnit – každá kopie (klon) může být v roli „klienta“ i „serveru“.
Z těchto vlastností vyplývají výhody distribuovaných verzovacích systémů:
.hg
, .git
nebo .bzr
máme v každém úložišti jen jednou,
zatímco .svn
se nám vždy rozlezlo i do všech podadresářů, což komplikuje např. nasazení aplikace, protože tyto adresáře musíme filtrovat.
Šikovnější je také práce s větvemi a štítky.
Přestože i starší systémy uchovávají jen rozdíly a vytvoření větve nebo štítku téměř nic nestojí,
v pracovní kopii např. v Subversionu se objevují soubory ze všech větví najednou – obvykle tu máme:
/trunk
(hlavní větev, kmen),
/tags
(štítky) a
/branches
(větve).
Na straně klienta tak máme všechny soubory v několika kopiích, což jednak může zabírat dost místa
a jednak musíme projekt v IDE nebo v editoru otevírat v různých adresářích.
V modernějších systémech jsou soubory pořád na stejném místě a mezi jednotlivými větvemi nebo štítky se přepínáme
(soubory se aktualizují, ale jsou pořád ve stejném adresáři).
Možná se teď ptáte, jestli jsou distribuované systémy jen skvělé a bezchybné, nebo jestli mají oproti svým centralizovaným příbuzným i nevýhody – nějaké se najdou:
Tyto nevýhody nejsou nijak zásadní a neměly by vás odradit od distribuovaných verzovacích systémů, nicméně je dobré o nich vědět.
Ve čtvrtek budeme pokračovat hlubším představením distribuovaných verzovacích systémů a tím bude úvod uzavřen.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
title="třeba to pro vás bude impulzem k používání štítků (tagů)"
. Štítky to lineární číslování nejen nahrazují, ale jsou i lepší, protože umožňují označit verze, které jsou z nějakého důvodu zajímavé. Osobně mi to lineární číslování nechybí, ale vím, že je to častý argument/stížnost, proto tam v tom výčtu je.
Hezky uvod, tesim se taky na pokracovani. S gitem chci uz dlouho zacit pracovat, ale moc jsem se k tomu nedostal.Vřele doporučuju. Zkusil jsem si s ním pracovat na jednom maličkém projektu (asi tak 4 soubory) a teď ho už používám zásadně na všechno.
Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?Já myslím, že jediný rozdíl bude ve velikosti metadat svn a git-u, protože odhaduju, že se verze ukládají velmi podobně, takže objem "verzovaných" zdrojových kódů bude asi cca stejný... Ale docela by mě zajímalo srovnání.
Druhej dotaz se tyka struktury. Subversion muzu checkoutovat do FS a vsechno funguje normalne, takze muzu mit v subversion systemovou konfiguraci /etc a zmeny pak ukladat do svn. V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git? Tuaim v projektech unionfs, aufs nebo squashfs jsem videl docela divnou strukturu kopie git repa, ikdyz ted jsem na to koukal a vypada to normalne, je tam jen .git navic, podobne jako .svn. Tak uz se tesim na dalsi dily.S gitem je to samozřejmě stejný, stačí dát v /etc příkaz git init a pak (pokud chceme všechny soubory) tak git commit -a. No a pak už jen jednotlivé commity. BTW: v Debianu (potažmo i v Ubuntu) je na tom postaven jeden projekt, jmenuje se etckeeper a dokonce má na výběr, takže kromě git-u lze použít i bazaar, mercurial nebo darcs.
Nevím jestli jsem to dobře pochopil, ale mám dojem že git ukládá jednotlivé verze jako celek, nikoliv sérii změn (myslím že je to napsáno někde v Pro Gitu). Neupravené soubory asi ne, ale upravené myslím ukládá "vždy znovu". Nevím přesně co to má za výhody, jedna z nich myslím byla že se při požadavku určité revize šáhne přímo pro ni a nemusí se procházet celý strom.Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?Já myslím, že jediný rozdíl bude ve velikosti metadat svn a git-u, protože odhaduju, že se verze ukládají velmi podobně, takže objem "verzovaných" zdrojových kódů bude asi cca stejný... Ale docela by mě zajímalo srovnání.
Ale objekt není soubor.
mkdir foo cd foo/ git init echo "soubor" > soubor git add soubor; git commit -a -m "soubor" find . -type f -cnewer soubor ./.git/refs/heads/master ./.git/objects/fc/241abf0b9836924d289cc42fe1f218c5c78bf8 ./.git/objects/40/6fd5394c9e862fe7b6086437c9b5ef22b6e3b5 ./.git/objects/26/3e889a65bde2f9eefcc954003ecbc134d5d342 ./.git/index ./.git/COMMIT_EDITMSG ./.git/logs/refs/heads/master ./.git/logs/HEADVe výchozím stavu ukládá git objekty do jednotlivých souborů. V tomto případě vytvoří tři objekty - strom, commit a blob. Až po volání git-repack a git-gc se jednotlivé objekty uloží do pack souboru.
To jo, objekty ukládá do souborů, ale nějaký main.c není objektem, tím je až např. commit.Soubor (v gitové terminologii blob) je jedním z typů objektů v gitu, takže nemáte pravdu.
Já myslím, že jediný rozdíl bude ve velikosti metadat svn a git-u, protože odhaduju, že se verze ukládají velmi podobně, takže objem "verzovaných" zdrojových kódů bude asi cca stejný... Ale docela by mě zajímalo srovnání.
Zrovna tento predpoklad je dost chybny .... vetsina VCS pouziva sady zmen -- diffy , git uchovava cele soubory ( i kdyz je komprimuje)
Zrovna tento predpoklad je dost chybny .... vetsina VCS pouziva sady zmen -- diffy , git uchovava cele soubory ( i kdyz je komprimuje)Zajímavé na tom je, že gitovské celé soubory často zaberou míň místa než SVNkové diffy :).
$ git init Initialized empty Git repository in .../.git/ $ touch soubor $ git add soubor $ ll total 0 -rw-r--r-- 1 jirka jirka 0 25. led 21.17 soubor $ git commit -m "asas" [master (root-commit) c4a878f] asas 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 soubor $ chmod 0600 soubor $ git add soubor $ git commit -m "asas" # On branch master nothing to commit (working directory clean) $ ll total 0 -rw------- 1 jirka jirka 0 25. led 21.17 soubor $ chmod 0700 soubor $ git add soubor $ git commit -m "asas" [master f5829cd] asas 0 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 souborZdá se, že komplet práva, co vidíš, jsou vycucaná z prstu.
Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?Přiznám se, že takhle velké úložiště jsem nikdy neměl (nejvíc řádově asi 10x menší v P4), ono je i lepší verzovat jen ta nejcennější data (zdrojáky + minimum binárek) než tam dávat všechno. Takové zkompilované binárky vydaných verzí patří spíš na sdílený disk – jednak to jsou data, která není potřeba verzovat (jen přibývají), a jednak to člověka trochu dokope k tomu, aby byl schopný kdykoli sestavit libovolnou verzi (nemělo by se stát, že máš někde binárku/balíček
aplikace-v1.2.3
a když o ni přijdeš, tak nevíš, jak ji znova vyrobit).
Jinak ta náročnost při přechodu na nějaký DVCS bude řádově stejná nebo menší, neměl by to být problém. Akorát bych zvážil, jestli to nejde nějak rozdělit nebo vyházet zbytečnosti.
Subversion muzu checkoutovat do FS a vsechno funguje normalne, takze muzu mit v subversion systemovou konfiguraci /etc a zmeny pak ukladat do svn. V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git?Přesně na tohle používám Mercurial, Git půjde použít taky. Navíc tyhle systémy jsou vhodnější (.svn se rozleze do všech podadresářů)
cd /etc hg init chmod 700 .hg hg addremove hg commitNa to nastavení práv nezapomínat – protože kdyby byl
.hg
čitelný pro všechny, mohl by z něj neprivilegovaný uživatel vytáhnout nějaká tajná data (klíče, hesla atd.).
Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?Do toho se pouštět nebudu, ale pokud používáte verzování mixu zdrojáků a binárek, doporučuju každé do vlastní větve, ať se s tím dá v budoucnu něco udělat (větve spolu nemusí souviset, a neříkám nic o tom, jestli na to má být samostatný repozitář nebo ne).
V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git?Jde, jen můžeš narazit na to, že git nemá úplně stejné vlastnosti jako SVN. Ale rozhodně to jde.
akorát bych si musel vytvořit hook na commit a pushPo takové "degradaci" gitu na svn přijdeš o spoustu dalších vychytávek a zůstane ti jenom bleskurychlé prohlížení historie. Výhodou odděleného
commit
a push
je to, že větší sadu změn lze snadno rozdělit (commitovat) na řadu menších patchů a pushovat až výsledek. Navíc lze lokálně dělat spoustu věcí jako rebase -i
, alias hergot, teď v šestém commitu v mojí sadě je pitomý překlep.
Navíc git umožňuje spolupráci i v případě, že nemám přístup do centrálního repository - třeba do Linusova stromu nemá přístup nikdo jiný, než on a kód se do něj dostává přetahováním změn z ostatních stromů. Nebo send-patch
je šikovná metoda přispívání do projektu, aniž by se musela řešit administrativa s přístupovými právy. Hezkým důsledkem je, že Linusův strom je hlavní pouze proto, že se na tom většina vývojářů shoduje - technicky není problém vyhlásit za nový hlavní strom strom kkohokoli jiného.
Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci.No synchronizace vzdálených a lokálních dat je základním předpokladem pro každý slušný systém pro správu verzí, ne? Však v zásadě jediné, co git clone oproti svn checkout dělá navíc je to, že stáhne všechny revize všech souborů, které si udržuje ve stromu revizí.
Navíc lze lokálně dělat spoustu věcí jako rebase -i, alias hergot, teď v šestém commitu v mojí sadě je pitomý překlepPřesně, díky rebase se s klidem můžeš prohlásit ("podívejte se na historii") za neomylného programátora, který na všechno myslí dopředu. Teda aspoň do chvíle, než ten kód nahraješ někam ven.
Pracuju sám stylem svn update, práce na projektu, svn commit a proto potřebuju mít všude poslední data. Což centrální svn splňuje už z principu. Proto nějak nevidím důvod (a výhody) VCS. Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge). Zcela totéž bych ale musel řešit u Dist. VCS
snad jen, že nezávisíš na jednom centrálním stroji při vývoji
Vzhledem k tomu, že ten stroj na kterém jsem pracoval před hodinou je teď nedostupný, tak to stejně musím commitnout na nějaký centrální bod.
Možná to jen špatně chápu, ale třeba to někdo vysvětlí:
Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních). Tedy i ten distribuovaný VCS musí mít někde centrální bod (a má) kam jednotlivý vývojáři udělají push a z něj něco jako update.
No a teď, v článku je naznačeno, že v případě výpadku se může udělat centrální uzel z libovolného jiného uzlu. No ale jak, když tento uzel v typickém případě zcela jistě nebude mít data synchronizovaná s tím bývalým centrálním? Tedy bude v nějakém starším čase.
Možná to půjde řešit tak, že na tento nový uzel všichni ostatní pushnou práci vytvořenou od toho staršího času, ale to mi přijde jako dost ruční práce.
Možná je jen problém, že si to celé představuju jako multimaster replikaci.
No ale jak, když tento uzel v typickém případě zcela jistě nebude mít data synchronizovaná s tím bývalým centrálním? Tedy bude v nějakém starším čase.To vyloženě záleží na tom, jak často si ostatní synchronizují úložiště s tím původním centrálním serverem. Což - pokud na nových vlastnostech pracují ve svých samostatných větvích a to by měli - můžou dělat třeba každou hodinu. Ale jinak jo, asi by se v takovém případě musel vzít nejaktuálnější uzel a do něj ručně našoupat novější změny, to znamená ruční práci stejnou, jako když se to šoupalo do původního centrálního serveru.
Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge).Dál na tom projektu pracovat můžete, slučování nebudete dělat ručně, ale udělá to VCS. Samozřejmě pokud chcete editovat ten nový kód, potřebujete ho – ale k tomu nepotřebujete nutně mít všude poslední data, stačí si s sebou třeba vzít ten poslední commit.
Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních).Nepotřebuje a zpravidla ani nechce. Od ostatních chci mít odladěný a funkční kód, ne to, co mají zrovna rozpracované. Pokud už na něčem pracuju s kolegou, chceme si vyměňovat kód jenom mezi sebou – když mi upraví rozhraní, chci jenom to změněné rozhraní, nechci si kvůli tomu z centrálního úložiště stahovat neodladěný kód všech ostatních a řešit třeba jejich změny rozhraní. S DVCS mi jen kolega pošle ten správný commit, nebo si vytvoříme společný centrální bod jen pro nás dva, nebo si vytvoříme novou větev. V centralizovaném VCS bychom museli vytvářet novou větev, a s tím se kvůli jednomu souboru opravdu nikdo dělat nebude. Takže pak (třeba se SVN) skončíte tím, že si ten jeden změněný soubor pošlete e-mailem, takže vaše představa o aktuálním kódu v centrálním bodu je jen iluzí, ve skutečnosti je aktuální kód roztroušený někde v e-mailech.
Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních). Tedy i ten distribuovaný VCS musí mít někde centrální bod (a má) kam jednotlivý vývojáři udělají push a z něj něco jako update.
Nemusí. Např. na githubu si najdeš projekt, který se ti líbí a potřebuješ do něj jednu změnu. Uděláš si fork, přidáš svoji fíčuru a provedeš commit a push. Původnímu autorovi se tvoje změna může líbit a přetáhne ji k sobě, nebo pokračujete ve vývoji každý zvlášť. Takových forků může být spousta a žádný není hlavní. Linusův kernel je ten hlavní z politicko-manažerských důvodů, ale z hlediska správy verzí je rovnocený s Ingovým nebo Tedovým.
Pravda, v komerční komerční praxi to není obvyklý model. Ale oddělení commit a push má svůj význam. My používáme svn, všichni jedeme z trunku, protože slučování větví je opruz. Zároveň je to záloha pro případ havárie mého notebooku. Jenže když dělám nějaký větší refactoring, který by ovlivnil ostatní nemůžu ho commitnout dokud není hotový a otestovaný. Nebo kolega, který s oblibou doma bez VPN po nocích opravuje všechno napříč aplikací. Ráno přijde do práce, udělá megacommit 5 oprav a 2 nových feature v jednom. U distribuovaného systému by to v noci commitoval a ráno v práci pushnul.
Jinak tenhle úvod je zajímavý, ale přínosnější by byly články z praxe o přechodu ze SVN na distribuovaný systém. My jsme třeba vzdali přechod na Mercurial, protože neumí checkout podadresáře, což je pro nás vzhledem k historickému layoutu repozitáře zásadní problém.
Možná to půjde řešit tak, že na tento nový uzel všichni ostatní pushnou práci vytvořenou od toho staršího času, ale to mi přijde jako dost ruční práce.
Kazdy si nastavi novy hlavni server jako defaultni remote, a vsichni kteri maji praci, ktera na tom novem 'hlavnim serveru' pak provedou "git push" (nebo ekvivalent v jinem VCS, eventuelne synchronizuji jinou metodou (spravce udela pull, nebo tak neco)). Je to bez cehokoliv dalsiho (tedy skutecne jen napisi "git push" a stisknou enter). Vzhledem k tomu, ze pushuji pravidelne tak je jeden push navic nezabije.
Pokud nejaky vyvojar chce aktualni praci jineho vyvojare (bez ohledu na vypadek hlavniho serveru, ten druhy vyvojar z nejakeho duvodu jeste nemusel pushovat), tak si to proste od nej pullne (za predpokladu ze ma cteci pristup do jeho repozitare). Tak muze napriklad spravce projektu pullnout k sobe, zkontrolovat jestli to dela co ma a pak pushnout na 'distribucni' server, jako oficielni verzi.
Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge).Dlouholetý uživatel svn se pozná tak, že mu při vyslovení "merge" naskočí husí kůže
D | C | B | AJá udělám změnu E1, a když pullnu kolegův repozitář, zjistím, že on udělal změnu E2, která také vychází z verze D.
E2 E1 | / D- | C | B | AZměnu E1 proto rebasnu - upravím "patch" tak, že nevychází z verze D, ale z verze E2 (a končí stejným stavem zdrojáků). Dostanu tak:
E1 | E2 | D | C | B | AKolega si pullne můj repozitář a jede se dál. Nebo můžu udělat merge, pak ale získám:
M- | \ E2 E1 | / D- | C | B | ATohle se dělá v gitu naprosto běžně, nejsou s tím problémy a je to rychlé (časová náročnost merge roste jenom s velikostí zdrojáků/změn, ne s počtem commitů ve větvích, na běžném počítači nepostřehneš, že se něco děje).
Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních). Tedy i ten distribuovaný VCS musí mít někde centrální bod (a má) kam jednotlivý vývojáři udělají push a z něj něco jako update.Technicky nemusí. To je jen jeden ze způsobů práce. Ale typicky, každý projekt, sebevíce decentralizovaný, mívá nějaké oficiální verze na jednom oficiálním místě typicky spravovaném jedním člověkem. Decentalizace nespočívá v tím, že zrušíš hlavní úložiště, ale že můžeš pracovat i bez něj a v extrému se může používat třeba pouze pro distribuci a klonování při zakládání nových větví.
No a teď, v článku je naznačeno, že v případě výpadku se může udělat centrální uzel z libovolného jiného uzlu. No ale jak, když tento uzel v typickém případě zcela jistě nebude mít data synchronizovaná s tím bývalým centrálním? Tedy bude v nějakém starším čase.Jednoduše, když se z ně stane centrální uzel, tak se do něj postupně dostanou ztracené změny znovu, protože je někdo vždycky má.
Možná to půjde řešit tak, že na tento nový uzel všichni ostatní pushnou práci vytvořenou od toho staršího času, ale to mi přijde jako dost ruční práce.Tahle ruční práce je ale každodenní záležitost buď vývojářů (centralizovaný model) nebo začleňovačů (složitější modely).
Možná je jen problém, že si to celé představuju jako multimaster replikaci.Na multimaster replikaci je problém to, že jednak musí být automatizovaná, což VCS typicky není, a druhak v multimaster typicky není definovaná hierarchie, což u lidmi řízených projektů typicky je.
Pracuju sám stylem svn update, práce na projektu, svn commit a proto potřebuju mít všude poslední data. Což centrální svn splňuje už z principu. Proto nějak nevidím důvod (a výhody) VCS. Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge). Zcela totéž bych ale musel řešit u Dist. VCSCo je na merge vlastniho kodu spatneho?
Možná je jen problém, že si to celé představuju jako multimaster replikaci.Ale ano, muzete to brat jako multimaster replikaci. A distribuovane VCS toho schopne jsou. Ale to by postradalo smysl pro typicky vyvoj produktu, spise se na to lze divat jako na strom, kde v koreni je obvykle to, co pak release engineering vezme a postavi nad tim vysledny produkt. Pripadne je to les takovych stromu.
Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci. Jinými slovy po prvním checkoutu se to vzájemně rozpadne a všude budou jiná data.Pokud máš všechny uzly pod kontrolou ty sám, tak to není problém; záleží na tom, jestli chceš, aby ve všech uzlech byla jiná data, nebo ne. Když chceš synchronizaci, tak prostě jeden uzel prohlásíš za hlavní (třeba jako bare repository) a na všech ostatních, když něco změníš, tak to do něj nahraješ a odtud potom distribuuješ na ostatní uzly. Jak je řečeno i v článku, Git se v tomhle umí chovat jako SVN (tj. jeden centrální server) Když chceš jiná data na každém uzlu, tak bych to viděl na větve.
To jsem myslel pro případ, kdy je slučování změn primárním požadavkem (např týmová práce na jednom dokumentu), pak by to bylo dost použitelné.
Aha, tak na toto je vhodnější wiki engine.
Tady se projevuje výhoda textových formátů -- např. XHTML nebo DocBook, případně LaTeX nebo nějaký wiki formát (třeba Texy).Nebo abiword
Nebo abiwordVedle. AbiWord je název aplikace, jejích nativní formát je postavený nad XML (teda aspoň podle wikipedie), takže žádný zázrak.
Myslím, že Tortoise SVN nebo něco takového umělo udělat diff wordovského dokumentuTak já se s tím setkal poprvé u gitu, ale volat externí diff umí skoro každý VCS, ne?
Naopak, na tohle je lepší SVN!Aspoň jeden skutečný argument? Vykřičník argumentem není.
Přinejmenším se z SVN dá udělat WebDAV serverHmm, argument z neznalosti, bezva.
který pak funguje (při "autocommit") navenek jako síťový server, ale ve skutečnosti ukládá jednotlivé verze...Tím, že uvedeš společnou feature dvou systémů těžko dokážeš, že je jeden lepší.
Argument je jednoduchý: SVN je navržen, aby fungoval jako centrální úložiště, git je navržený jako centralizovaný...Naopak, na tohle je lepší SVN!Aspoň jeden skutečný argument? Vykřičník argumentem není.
...to že někdo dobastlit WebDAV do gitu na tom nic nemění.který pak funguje (při "autocommit") navenek jako síťový server, ale ve skutečnosti ukládá jednotlivé verze...Tím, že uvedeš společnou feature dvou systémů těžko dokážeš, že je jeden lepší.
fungoval jako centrální úložiště, git je navržený jako centralizovaný...Skoro mám pocit, že jsi chtěl říct decentralizovaný, ale i tak je to jedno. Git je navržen tak, aby fungoval, jak potřebuješ. Centralizovaně/decentralizovaně - můžeš si vybrat.
Argument je jednoduchý: SVN je navržen, aby fungoval jako centrální úložiště, git je navržený jako centralizovaný...Když vynechám překlep... to, že neznáš Git a nevíš, jak fungují a k čemu se používají DVCS není zrovna důvod k radosti a sebejistým tvrzením o tom, na co se hodí nebo nehodí.
...to že někdo dobastlit WebDAV do gitu na tom nic nemění.Že je to nabastlené v SVN mě taky moc nebere. WebDAV je vcelku primitivní rozhraní, není to žádná černá magie. A popravdě řečeno je to na /etc dost nepoužitelné.
Používám SVN právě proto, že je centralizované. Ještě jsem nepřišel na výhody decentralizovaných VCS, akorát bych si musel vytvořit hook na commit a push. Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci. Jinými slovy po prvním checkoutu se to vzájemně rozpadne a všude budou jiná data. Toto snad objasní další díly.Když si jednou zvykneš, už se nebudeš chtít nikdy vrátit k centralizovaným. Vzájemná synchronizace je (může být) stejná jako u SVN, akorát se používá pull a push místo update a commit. Při centralizovaném způsobu práce s gitem (i tak má výhody oproti centralizovaným VCS) je jediný rozdíl v tom, že commituješ lokálně, pak dáš pull, abys byl aktuální, opravíš případné konflikty (stejně jako v SVN), a dáš push, který pošle všechny tvé commity včetně toho, který ty dvě linie vývoje spojuje opět do jedné. Takže v historii to je vidět. Příkladem výhody DVCS proti centralizovanému při použití centrálního repozitáře je například práce offline, která v SVN prakticky nefunguje. Takže nic těžšího než SVN. No a když se dostaneš kousek dál, tak oceníš lokální větve, možnost synchronizace mimo centrální úložiště (testování práce kolegy, autonomní týmy, lokální úpravy použitých opensource knihoven s pozdějším začleňováním do upstreamu, atd...). Ale to už je další level.
opravíš případné konflikty (stejně jako v SVN)Akorát je šance, že těch konfliktů bude u SVN míň...
Jistě, ale to záleží právě na charakteru změn, jejich počtu a počtu autorů...Spíš jenom na charakteru změn.
Akorát je šance, že těch konfliktů bude u SVN míň...Pokud budeš git používat dostatečně hloupě, tedy jako SVN, tak bude konfliktů úplně stejně.
Protože neposkytuje žádné rozumné argumenty...Taky jsem na žádné rozumné argumenty neodpovídal.
To je ideologický blábol.Ne to je technicky podložený fakt. Vzhledem k tomu, že Git i SVN používají velmi podobné metody řešení konfliktů, při stejném způsobu práce budou úplně stejné konflikty a budou se řešit úplně stejným způsobem. Ideologický blábol je to, že Git způsobuje konflikty.
Když si jednou zvykneš, už se nebudeš chtít nikdy vrátit k centralizovaným.To je teda argumentace jako z reklamy na jogurty...
takže taky nemám důvod, abych se snažil ostatní přesvědčit, že by jeden systém měl být nejlepší za všech okolností a na všechny typy nasazení...práve naopak... toto robíš tu celý čas...
Naopak. Ukazuju na rétorickou figuru „už se nikdy nebudeš chtít vrátit“, která se používá v marketingových kecech, když se chtějí zamlžit skutečné argumenty.Asi se moc koukáš na televizi, já za posledních několik let reklamu na jogurt neviděl.
Koneckonců, já nedělám školení na žádný verzovací systém, takže taky nemám důvod,Ani bych ti to nedoporučil :).
abych se snažil ostatní přesvědčit, že by jeden systém měl být nejlepší za všech okolností a na všechny typy nasazení...Pokud vím, tak prosazuješ Subversion. Sice asi na určitý typ nasazení, ale neuvedl jsi jediný platný argument, proč by svn mělo být na ten účel lepší. Takovým pokusem byl možná WebDAV, ale ani to se ti moc nepovedlo. Kdybys u toho zůstal, nikdo by ti nic nevyčítal, ale když přejdeš od argumentů k pouhým chabým pokusům druhého shodit, tak nečekej, že si z tebe sednou všichni na zadek.
To je teda argumentace jako z reklamy na jogurty...Jenom proto, že ty nemáš žádný pádný argument, nemusíš někoho urážet. Ale pravda, můžeš, tohle je otevřené fórum, ztrapňuj se dle libosti.
rebase
je určený k jakýmkoli změnám historie za aktuálním HEADem (na ten stačí commit --amend
): přeházení pořadí commitů, jejich úprava, slučování i rozdělování, změna commit message, prostě co si člověk představí.
Myslim, ze vhodny je merge:
git merge --no-ff --no-commit --log vetev
git commit -e
V kapitole Trocha historie je na konci druhého odstavce "jsou kompilovány sami sebou"; mělo by být "jsou kompilovány samy sebou".
V kapitole Co jsou verzovací systémy a k čemu jsou dobré je na konci odstavce Týmová spolupráce "Odpadnou vám starosti s ... věčném otravném kopírování souborů z poštovního klienta na disk a opětové vkládání do e-mailů"; mělo by být "Odpadnou vám starosti s ... věčným otravným kopírováním souborů z poštovního klienta na disk a opětovným vkládáním do e-mailů", případně "věčné otravné kopírování souborů z poštovního klienta na disk a opětovné vkládání do e-mailů", vztahuje-li se odpadnutí pouze na starosti s přepisováním souborů na disku. Snad jsem se do toho nezamotal...
git clone --depth 1 git://git.example.com/project.git git submodule --help
má každý celou historii - u velkého projektu to zabírá hodně místaTo není žádná nevýhoda. Doba 20MB disků je dávno pryč.
Stejně tak i nemožnost klonovat jen podstrom celého vzdáleného uložiště.K čemu by to bylo dobré? Akorát by se navíc muselo řešit vyhazování diffu souborů mimo ten podstrom při synchronizaci. Zbytečná práce navíc.
Klonovat podstrom je obezlicka, ktera vznikla v tech VCS, kde se neni rozlisena semantika nekterych obektu. Mam na mysli branche a tagy versus podadresare v svn. To se pak zacalo vyuzivat (zneuzivat) i jinak. Vetsina distribuovanych VCS uz ma rozlisenou vetev a podadresar. Pokud ma byt neco samostatne vyvijeny projekt, tak to ma mit vlastni repozitar. Dalsi vec je i ta, ze u DVCS typu git z principu nemuzes povolit/zakazat pristup k castem stromu. Pokud nema mit k casti stromu nekdo pristup, resi se to novym repozitarem pro tu cast stromu.
Uvedu priklad: mam v archu nastaveni ssh, vcetne pomocnych skriptu. Ty skripty jsou verejne, ale to nastaveni je soukrome. Checkoutuju to dohromady, nicmene jsou to dva repozitare. Kdokoli si muze skripty checkoutovat primo ode mne, zatimco konfiguraci si nejak zajisti sam.
Pokud nema mit k casti stromu nekdo pristup, resi se to novym repozitarem pro tu cast stromu.Ono to ani jinak nemá moc smysl.
Uvedu priklad: mam v archu nastaveni ssh, vcetne pomocnych skriptu. Ty skripty jsou verejne, ale to nastaveni je soukrome. Checkoutuju to dohromady, nicmene jsou to dva repozitare. Kdokoli si muze skripty checkoutovat primo ode mne, zatimco konfiguraci si nejak zajisti sam.Doplním vlastním příkladem. Mám systém na generování webovek (sada skriptů v AWK, která generuje makefiles a za jejich pomocí generuje celý web, momentálně přepisuju do perlu) a zdrojové soubory webovek (wiki-like formát + metadata). Typicky můžu chtít stejný systém použít v kombinaci s jinými daty a skripty zveřejnit, zdrojáky webovek není potřeba zveřejňovat :), ať se lidi podívají na výsledek.
V zájmu objektivity mi tam chybí nejzásadnější nevýhoda, a tou je právě, že má každý celou historiiNemusí mít, viz výše, ale samozřejmě obětuješ část výhod. Navíc třeba u gitu těch dat v praxi (zdrojové kódy) zase tolik není.
Stejně tak i nemožnost klonovat jen podstrom celého vzdáleného uložiště.To není pravda, DVCS neimplikuje nemožnost klonování podstromu. Nicméně třeba git dovoluje pracovat jen s explicitně vytvořenými podstromy (submodules). Ale tak jako tak nelze přenášet vlastnost gitu na obecné omezení DVCS. Navíc i do gitu by to šlo doimplementovat, ale zřejmě o to nikdo moc nemá zájem.
ziskate intuitivni multiplatformi nastroj (mimo jine s vestavenou podporou centralizovaneho pristupu).Pak tedy nevidím důvod, proč ho (Git) nepoužít.