KdokolivNemáš pravdu. I checkout na filesystemu 8.3 lze provést bez rozbití. Z pohledu verzovacího systému, samozřejmě. Pokud tam máš například C++ kód a odkazuješ se na header mající ve jméně víc znaků než 8.3, pak ano, o určitém rozbití lze mluvit. Ale nikoliv o rozbití repozitáře. Klient si klidně může udělat překladovou tabulku a jména souborů zakódovat do podoby, kterou třeba používá(l) Windows 95, tj ve tvaru JMENOS~1.TXT.
Ani s tím druhým nesouhlasím. Verzovací systém podle téhle logiky totiž nemusí ani podporovat Branch & Merge. Degraduješ verzovací systém pouze na Backup & Restore. Ale tak to není, verzovací systémy mají umožnit zejména jednodušší vývoj a správu zdrojových souborů. Umožnit třeba vyvíjet více alternativ a přitom udržet nějakou rozumnou míru přehlednosti a integrity. A právě možnost vytvářet hardlinky se schopností se automaticky aktualizovat patří mezi nástroje Branch & Merge. Pokud si totiž branchnu půlku (nebo celý) projekt s tím, že chci stále mít aktuální určitou část projektu, na které nebudu pracovat, pak mi nezbývá, než maunálně mergovat. Kromě opruzu, to zbytečně zabírá místo v repozitáři, protože jde o dvě nezávislé větve u kterých prostě přestalo fungovat COW.
Mezi věci, které by měl verzovací systém umět podle mého názoru je třeba možnost dynamického mergování (soubor vzniká mergem z několika zdrojů), propagace změn jedním směrem (můj commit obsah souboru nepropaguje, ale commit z ostatních sdílení se automaticky zamergují). A podobně. Mohu ti říct, že není větší opruz, než když jsi připraven provést merge do trunku a po tom, co to uděláš zjistíš, že mezitím přišel nějaký blbec z vedení a rozhodl se totálně překopat celou knihovnu, na které je tvůj projekt závislý. Kdyby existovala možnost automatické aktualizace, dozvěděl by ses třeba o tomto kroku dřív a neztratil bys dny, či týdný vývoje zbytečnosti. |
Registrace nového uživatele 
