Apache Subversion 1.12

Byla vydána verze 1.12 systému pro správu a verzování zdrojových kódů Apache Subversion (Wikipedie). Přehled novinek v poznámkách k vydání.

25.4.2019 12:22 | Ladislav Hagara | Nová verze

Komentáře

[Zdenek 'Mst. Spider' Sedlak]

Super

[Hryzo]

Ako moze niekto toto aktualne pouzivat.Kazdy normalny systemak zmigroval uz davno na iny DVCS

[pacholik]

na DVCS

[Zdenek 'Mst. Spider' Sedlak]

To vis, ze jo, systemaci si rozhoduji, jaky VCS/DVCS budou pouzivat

SVN ma par uzitecnych use-cases i v dobach Git/Hg/Bzr

[dustin]

Jaké třeba konkrétně? Díky.

[Zdenek 'Mst. Spider' Sedlak]

Pro je jednoho klienta jsem delal SVN cluster pro verzovani jejich vlastnich dokumentu, kde SVN podavalo lepsi vysledky nez Hg. Git uplne propadl. Jinak pro bezne dev tymy davam Git/Hg, tam uz se SVN moc nechyta.

Delta-algoritmus ma SVN pekne promakanou a dost featur si berou z DVCS.

Ono je totiz dobre si precist release notes, nez zacit neco kritizovat - SVNM 1.12 neni SVN 1.0 a kluci udelali poradny kus prace.

[Heron]

Docela zajímavou vlastností svn je to (možná bylo, už jsem svn roky neviděl, tak nevím, zda to je tam stále), že se dá checkoutnout libovolný podstrom z repa a s tím dál pracovat (tj commitovat do něj). Takže jsem měl jeden repositář, v něm co složka to projekt a checkoutoval jsem si podstrom podle potřeby.

[Michal Kubeček]

Jak už tu padlo, ne na "jiný DVCS", protože subversion není DVCS.

Řekl bych, že existují dva typické důvody, proč projekty stále ještě používají subversion:

• Projekt historicky subversion používá, vzhledem k modelu vývoje ho neomezuje (typicky téměř lineární historie, větve se používají jen zřídka), většina vývojářů (často 1/1) je na subversion zvyklá a nic nového se učit nechce.
• Většina vývojářů (často 1/1) má oblíbené IDE, které má komfortní integraci subversion, ale ne něčeho rozumnějšího.

[sigma]

Umí Hg/Bzr (git vím, že ne):

• definovat oprávnění uživatelů na jednotlivé podstromy jednoho repository?
• naklonovat a dále plnohodnotně pracoat pouze s částí repository? (což je nakonec podmínka pro předchozí bod)

Toto je jeden z důvodů, proč s velkým projektem zůstáváme pořád u SVN. Máme repository s velikostí přes 10 GB (dokumentace k projektům vč. CAD dat a podobně) a další ne tak velké se SW projektem, kde ovšem každý vývojář nemá mít přístup ke všem zdrojovým kódům. Další důvod je, že nás nic moc neomezuje a kde ano, jdeme cestou oddělení dílčích subprojektů spravovaných přes git se synchronizací do master SVN.

[Michal Kubeček]

Pokud "oprávnění" znamenají to, kdo smí co měnit, tak to se i s gitem zařídit snadno dá. Pokud byste chtěl, aby uživatel část repozitáře nemohl ani vidět, pak se spíš nabízí otázka, jestli je opravdu rozumné to mít jako jeden repozitář. Ona mi celá ta vaše konstrukce vůbec připadá spíš jako typický use case na submodules.

Další důvod je, že nás nic moc neomezuje

To bude spíš ten hlavní důvod, i s ohledem na

a kde ano, jdeme cestou oddělení dílčích subprojektů spravovaných přes git se synchronizací do master SVN.

To zní ještě víc jako submodules.

[sigma]

Jde o to, že některé věci nesmí být ani vidět, a také že ne všichni potřebují celý 10+ GB strom.

Submodules by to možná řešily, ale musel by nad tím být ještě nějaký další tooling. Máme značnou část uživatelů, která nezvládne / nechce nic jiného než GUI, a integrace submodulů je v tomto ohledu dost špatná. Teď prostě dám svn update na celé working copy a vím, že mám všechny projekty které mě zajímají aktuální.

Těch subprojektů, co by musely být jako submoduly, je u jednoho z repozitářů několik desítek za rok. V současnosti stačí založit adresář ve správném místě v existující struktuře a případně upravit nastavení práv, což zvládne kdokoliv. GUI zároveň poskytuje přehledný katalog všech existujících projektů pro výběr co chci klonovat a co ne.

Uvažovali jsme o gitlabu, který na některé věci už dlouho používáme, ale byla by to dost velká změna paradigmatu, pro uživatele víc práce, a jiný přínos skoro žádný. Musel by založit projekt v gitlabu, přidat ho jako submodul do hlavního projektu, ... k tomu hlavnímu projektu by muselo být nějaké lepší GUI pro výběr, které submoduly mě zajímají a které ne.

[Michal Kubeček]

Jinak řečeno, jsou to nakonec vlastně ty důvody, o kterých jsem psal: jednoduchý workflow, pro který SVN není omezující, uživatelé jsou na to zvyklí, takže přechod by znamenal jen práci navíc a nutnost učit uživatele něco nového.

[Hryzo]

Suhlas,tiez mi to pripada ako legacy / nevhodny navrh architektury projektu.Ak uz tak velmi potrebujem,tak mam submodules. A inak si riesim dependency uplne inymi mechanizmami na urovni zostavovani projektu. A ako funguje kolaboracia viacerych userov na centralizovanom VC? To musi byt radosti stale updatovat pre kazdy commit. A v dobe,kedy svetu vladne git a hosting projektov na githube + pull requesty + code review a CI/CD pipeline by som zamestnanca,ktory mi povie,ze sa nebude ucit GIT (alternativne HG) asi rovno vyhodil.

[sigma]

1) (D)VCS se dají použít i na jiné případy než zdrojové kódy software. Pak problémy typické pro vývoj SW, které výhodně řeší distributed model, vůbec nenastávají, a naopak nastávají problémy jiné. Použití SVN spíš jako document management systému je celkem časté.

2) Ano, jeden z těch projektů je legacy věc. Takové existují, mají za sebou třeba 30 let vývoje, stabilní tým lidí s unikátní doménovou znalostí a nějaké zaběhlé workflow. Pokud máte v týmu lidi s unikátní znalostí určité problematiky, co jsou SW vývojáři jen napůl, a jinak dělají fyziku/mechaniku/matematiku, je skutečně nejlepší nápad je rovno vyhodit, když nemají aktivně zájem se přeučovat na jiný model, který je z jejich pohledu objektivně složitější, pokud jim k tomu nedodám nějaký další tooling. Oni se tomu aktivně nebrání, ale prostě by to neslo nějaké náklady, jejichž návratnost je diskutabilní. Takový legacy projekt může mít desítky komponent, build hlavní SW části probíhá pro 4+ velmi rozdílné platformy, build některých velmi obtížně nahraditelných komponent je "velmi specifický" a téměř všechno to má nějakou vazbu na to, že je to v SVN. V takové situaci migraci na git jistě zvažujete, ale třeba vám zatím vychází, že by to přineslo víc problémů a větší rizika než střednědobého užitku.