Software-update: Subversion 1.14.0

De Apache Software Foundation heeft Subversion 1.14.0 uitgebracht en het lts-stempel meegegeven. Subversion is een programma voor software- en projectontwikkelaars waarmee beheer en versiecontrole van software en broncode kunnen worden uitgevoerd. De ontwikkeling begon in 2000 bij CollabNet om een opvolger voor CVS neer te zetten, en in 2014 werd versie 1.0 uitgebracht. Sinds 2010 valt Subversion onder de Apache Software Foundation en wordt nog steeds verder ontwikkeld. Versie 1.14.0 bevat een groot aantal nieuwe features en verbeteringen. Dit zijn in het kort de belangrijkste verbeteringen:

What's New in Apache Subversion 1.14

• Support for Python 3.x
• Support for Python 2.7 is being phased out
• New Build-Time Dependency: py3c
• Many enhancements and bug fixes
• Known issues in the release

Apache Subversion 1.14 is a superset of all previous Subversion releases, and is as of the time of its release considered the current "best" release. Any feature or bugfix in 1.0.x through 1.13.x is also in 1.14, but 1.14 contains features and bugfixes not present in any earlier release.

Because 1.14 is the next LTS release following 1.10, these release notes describe major changes since 1.10, including changes released in 1.11.x through 1.13.x.

Versienummer	1.14.0
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Solaris, UNIX, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website	Apache Software Foundation
Download	https://subversion.apache.org/download.cgi#recommended-release
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (14)

[ari3]

Dit blijft toch de beste versiebeheertool in mijn ogen. Tegenwoordig wordt Git overal maar blind ingezet terwijl dat vaak veel complexiteit met zich meebrengt.

[henkbiertank]

Heb je weleens met Git gewerkt? Zo ja, heb je het voor langere tijd gebruikt? Voor mij is Subversion al wat jaartjes geleden dus ik kan het niet vergelijken met elkaar. Maar ik kan Git allesbehalve complex noemen. Het is natuurlijk maar net wat je gewend bent en wat je prettig vind werken

Toevoeging 11:08:
Ik heb in het verleden meegemaakt dat de git-server(s), waar ik bij een bedrijf werkte, per ongeluk waren gewist. Dan is de decentralisatie van Git toch wel erg fijn. Opnieuw pushen en we konden weer verder.

[Reactie gewijzigd door henkbiertank op 25 juli 2024 07:37]

[latka]

Ik gebruik Git en SVN naast elkaar (afhankelijk van klant/project). Voordeel van SVN: ik kan het aan mijn moeder uitleggen (dus ook de functionele beheerders en testers kunnen er mee werken en gebruiken het ook om testcases vast te leggen). Git is vaak sneller, maar ik kom iets te vaak puristen tegen die Git gebruiken om de historie zo te maken dat het een mooi verhaal wordt. In mijn ervaring is het hetzelfde als MS-Word gebruiken voor een notitie en dan 3 uur lang met font's gaan klooien. Of een timmerman die zijn hamer gaat versieren omdat het kan ipv. gewoon gebruiken om een spijker in de muur te krijgen. In mijn praktijk wordt er nauwelijks teruggekeken in de historie om te zien hoe een bug ontstaan is, maar wordt deze opgelost en wordt er gewoon naar voren toe gewerkt.

[Ventieldopje]

Als je het aanleert om netjes te doen is het evenveel moeite als het niet te doen. Sterker nog, je bespaard een hoop tijd als je atomische commits maakt. Je kan makkelijker branchen, cherry picken en individuele dingen terug draaien. Daar kom je snel genoeg achter als je iets kleins terug moet draaien dat in een massale commit zit als "ja werkt nu". Mag je lekker alle code door baggeren om alleen dat stukje te reverten en als je pech hebt nog in aanverwante code vroeten omdat je dit niet kan reverten zonder dingen stuk te maken.

Je vergelijking snap ik, het zal zo lijken maar in de praktijk blijft er niks van over.

[RoestVrijStaal]

Atomische commits zijn leuk.

Maar soms valt het werk niet op te delen in kleinere commits. Zoals bijvoorbeeld bij proof of concepts van het implementeren van een nieuwe feature bij een bestaande applicatie. Genoeg meegemaakt dat halverwege het ontwikkelproces toch anders opgezet moet worden. Het gevolg: een aantal commits die niet gedaan hoeven te zijn, maar die wel in de master worden gemerged als de feature af is. Je kan wel rebasen, maar dat is spelen met vuur.

Daarnaast wil ik op het einde van mijn werkdag mijn gedane werk in een remote branch hebben. Whatever de status van de code mag zijn. Want de werklaptop kan tijdens vervoer stuk gaan / gestolen worden als je hem naar huis meeneemt om de volgende dag thuis te werken vanwege corona / sneeuwval.

[Jeoh]

Om maar bij de timmermanvergelijking te blijven: Atomic commits is een timmerman die zorgt dat de juiste spijker in één keer in de muur geslagen wordt op de juiste plek, in plaats van een hamer te pakken en net zo lang spijkers in de muur te rammen tot er eentje op de goede plek zit.

[latka]

In mijn ervaring kan dat alleen als je 'schone' code hebt. Zodra de code op leeftijd raakt zijn de kruisverbanden niet meer te overzien en wordt de functionele vraag "knop op het scherm om xyz te doen" een hele serie codewijzigingen en blijft er van je mooie commit zowiezo niet meer zoveel over.

[JustFogMaxi]

Dan nog kun je alle wijzigingen voor die change in 1 commit stoppen. Heeft niks met spaghetti code te maken.

[Ventieldopje]

Wel als je terug gaat in de historie, wat het hele punt is van een VCS.

[stefanhendriks]

Misschien eens toch Git proberen. Git doet alles wat SVN kan maar beter/sneller. Sinds ik om ben gegaan is SVN verleden tijd voor mij.

Je kunt meer met Git , eens, dat maakt het wellicht complexer. Maar dat hoeft niet natuurlijk.

Los daarvan, merge conflicten oplossen met Git is een verademing vergeleken met SVN...

[Sebazzz]

SVN shelve werkt zo raar Als je daar shelved kan het op een grote monorepo zo minutenlang duren. Heel vreemd.

Ik ben blij dat ik op het werk alles van SVN naar git heb geconverteerd. Echt een verademing. De command-line experience is ook een stuk beter.

[RobinJ1995]

Git maak je zo simpel of complex als je wilt, maar het werkt wel gewoon. Dat kon een aantal jaren geleden van SVN jammer genoeg gewoon niet gezegd worden. Van alle versiebeheertools die ik tot nu toe heb gebruikt (Bazaar, Git, Mercurial, en SVN) is SVN toch wél echt bij uitstek degene die altijd het meeste technische problemen met zich meebracht.

[MrFax]

Het leukste was wanneer iemand een commit plaatste tegelijk met iemand anders. Ging altijd mis...

[RoestVrijStaal]

Volgens mij heeft dat meer te maken met het oplossen van (merge)conflicten (wat zowel bij SVN als bij Git geen pretje is), dan het versiebeheersysteem zelf.