Software-update: TortoiseSVN 1.11.0

Versie 1.11.0 van TortoiseSVN is uitgekomen, de tweede update van de grote 1.10-release. Dit programma is een gebruikersinterface voor Subversion, dat door ontwikkelaars wordt gebruikt voor versiebeheer. Het is haast onmisbaar als met verschillende mensen aan een project wordt gewerkt. TortoiseSVN integreert zich als een shell extension in Windows en kan zelfstandig of in combinatie met een ide worden gebruikt. Versie 1.11 van TortoiseSVN is gekoppeld aan Subversion versie 1.11 en de release notes voor deze uitgave kan hieronder worden gevonden.

Requirements

TortoiseSVN 1.10 and later requires at least Windows 7 or later. It won't run on Windows Vista anymore. If you're still need to use those earlier OS, you have to keep using TortoiseSVN 1.9 for Windows Vista or TortoiseSVN 1.8 for Windows XP.

Advertisement

Shelving and Unshelving

Subversion 1.11 has a new experimental feature called checkpointing which is enabled in TortoiseSVN 1.11. This feature allows you to shelve local changes, work on something else and commit and then unshelve those stored changes again. While in TortoiseSVN 1.10, shelving didn't work with binary files, in 1.11 it can deal now with binary files as well.

existing shelves

If you've created shelves in TortoiseSVN 1.10 and haven't applied them yet, please apply them before updating to TortoiseSVN 1.11. The old shelves can not be used in 1.11 anymore.

experimental

The shelving feature is still marked as experimental.

That means that while shelving works as advertised, it is still in a stage where it's heavily improved and worked on. That also means that there's no guarantee that the shelves you create are upwards compatible and future versions might not be able to use them. And of course the UI might change as well in future versions to accommodate new features and behaviors.

New icons

Most icons have been redesigned and improved. And they now all work better on high dpi monitors without looking blurry.

Various improvements

The UI now uses a consistent font over all dialogs.
The UI now works properly on high dpi displays.

Changelog

Changed:

• Splitter positions saved separately for log dialog and project monitor.
• Restored files get their last-write-time set to the current time.

Fixed:

• Display issues in the log dialog when resizing the dialog.
• When merging, the copyfrom revision was shown as eligible for merging.
• Long paths in the conflict dialogs were cut off instead of properly shortened.

Versienummer	1.11.0
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website	The TortoiseSVN team
Download	https://tortoisesvn.net/downloads.html
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (18)

[_Drum_]

Wat ik me afvraag, zouden er nog veel mensen / projecten gebruik maken van svn in plaats van git (en consoorten )?
Branching en merging is (in mijn ervaring) toch meer een nachtmerrie met svn dan met git.

[TabCam]

Het branchen en mergen ligt er helemaal aan hoe je het inricht. Als je duidelijke branches maakt,(ook wel gates genoemd) waarop je de ontwikkelingen integreerd, maak je het een stuk eenvoudiger.

SVN heeft een server nodig en dat maakt het al lastiger op te zetten. Vaak wordt Git ook gehost, maar je kan ook lokaal branchen en lmergen.

Als je eens echt eenvoudig wilt werken kan je ook naar Mercurial (Hg) kijken. Helaas is Mercurial niet grootschalig opgepakt maar de eenvoud, tooling en grafisch werken maakt dat het voor veel projecten mijn voorkeur heeft.

Alledrie de versiebeheerpakketten hebben hun eigen Tortoise. In de onderstaande link worden ze vergeleken:
https://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/

[elmuerte]

> SVN heeft een server nodig en dat maakt het al lastiger op te zetten.

Nee hoor, je kan lokale repos gebruiken. En als je bedoelt dat SVN een webserver nodig heeft, ook niet zo, er is namelijk ook svnserve, onderdeel van SVN.

[Farmerwood]

"The svnserve program is a lightweight server"

Klinkt toch echt alsof je er een server voor nodig hebt. ;-)
SVN is en blijft een systeem met een centrale server en geen distributie systeem zoals b.v Git en Mercurial. Of je die server of je lokale systeem kan draaien doet daar verder niks aan af.

[elmuerte]

Ik zeg toch ook dat je lokale SVN repos kan gebruiken, zonder server. Eerste hit op google: https://www.guyrutenberg....pository-home-repository/

[job_h]

Jullie definitie van "server" verschilt. Jij bedoelt exclusief de hardware, maar "server" kan ook naar een stukje software verwijzen.

Server software en client software kunnen op hetzelfde systeem draaien. Dan draait er dus nog altijd een server, terwijl dat allebei lokaal draait. Zie ook https://en.m.wikipedia.org/wiki/Client–server_model

Ik snap je opvatting wel. Wikipedia:

In computing, a server is a computer program or a device that provides functionality for other programs or devices, called "clients".

[elmuerte]

Nope, ik heb het niet over hardware maar over software. Er draait echt geen server software als je een local SVN repo gebruikt. Er is alleen een client. Geen server, geen daemon, helemaal niks. Het is pure directe file access.

[job_h]

Ok, dan snap ik je. Verkeerde aanname van mij.

Je hebt gelijk dat het zonder server via het file:// protocol kan. Maar aangezien het idee achter svn de server-client opzet is snap ik de verwarring ook wel

[Reactie gewijzigd door job_h op 24 juli 2024 08:10]

[TabCam]

Voor Mercurial heb je helemasl geen server nodig. Ook Git kan serverloos werken. Servers zijn alleen handig als je regelmatig verschillende ontwikkelingen wilt mergen.

[Farmerwood]

Dat zeg ik toch ook niet...?
In de praktijk wordt idd wel vrijwel altijd 1 repository als centrale repo aangemerkt waar iedereen heen pushen en vanaf pulled, maar dat is geen verplichting om met Git of Mercurial te kunnen werken.

[Reactie gewijzigd door Farmerwood op 24 juli 2024 08:10]

[TabCam]

Sorry, was een reactie op het bericht waarop jij reageerde, drukte op de verkeerde Reageer.

[NotHere]

Git heeft een behoorlijke learning curve. Ik heb bij een eerdere werkgever de overgang van svn naar git meegemaakt en het ging een aantal collega's erg lastig af.

De manier van werken die we hanteerden bij svn was dat iedereen naar dezelfde master branch pushte en dat code vervolgens gereviewed werd, terwijl het al automatisch op de test-omgeving gedeployed was. De enige branches die gemaakt werden waren de tweewekelijkse release-branches, en die werden nooit aangepast op eventuele hotfixes na.

De manier van "commit early commit often" en de branching strategy van Git is dan toch heel anders. Een stuk krachtiger, maar dan moet je wel de tijd nemen om de Git manier van werken te leren.

Ik kan me voorstellen dat er heel wat bedrijven zijn waar ze sinds jaar en dag SVN of Mercurial of wat dan ook gebruiken en zolang er geen nieuwe mensen met ervaring met Git binnenkomen, ze het nut niet inzien van overstappen.

Het lastigste van die overstap was overigens dat het gradueel werd gedaan, waardoor er een tussenperiode was waarbij de non-branching SVN projecten dependencies hadden op Git projecten die door het zelfde team beheerd werden. Dan moest je heel goed nadenken over de volgorde van je code reviews en merge to master of je testomgeving viel om.

[Qarlo]

Voor een omgeving met voornamelijk niet-programmeurs en of onervaren mensen zou ik nog steeds svn opzetten, zodat een onervaren en googlelende gebruiker onmogelijk hun gemeenschappelijke repository kapot kan maken.

[TabCam]

Je hebt hetzelfde probleem met SvN als iemand verkeerde code naar de server commit. Branches/integration gates gaan dat probleem tegen. Het maakt dus niet uit welk systeem je kiest, je moet altijd georganiseerd synchroniseren.

Het grootste voordeel van Git en andere gedistribueerdevomgevingen zoals Mercurial en Bazaar, is dat je dat soort commits er vrij snel uit hebt. In een centrale serveromgeving heb je er veel meer last van als het al gecommit is en er daarna weer met de server gesynct en daarmee verder ontwikkeld is.

[Boy]

Deze vraag was de reden waarom ik naar de comments ging kijken

[Verwijderd]

Ik dagelijks, wij zitten met een grote codebase die al jaren in svn wordt beheerd. Nieuwe projecten gaan in Git, maar de oude migreren we niet.

[Farmerwood]

Op mijn huidige werk gebruiken we voor een aantal projecten nog SVN.
Ik heb een poging gedaan om het om te zetten naar Git, maar liep uiteindelijk vast op de andere manier van het omgaan met externals/submodules.
Die huidige projecten (3 applicaties) delen een enorme codebase die als external in de 3 repositories zit. Wanneer je update gaat de external netjes mee, maar bij Git Submodules niet. Die tracken namelijk een specifieke commit en updaten niet automatisch naar de laatste commit in de branch die je gekoppeld hebt.
E.e.a was wel werkend te krijgen met wat losse acties die je steeds moet doen, maar het werkt niet handig en je vergeet het snel. Dus daarom is de overstap nooit gedaan. Ondanks dat we alle 4 de repositories netjes om hebben kunnen zetten naar Git met behoud van de volledige historie en branches.

Aangezien we ook eigenlijk van die structuur af willen wordt er niet heel veel werk van gemaakt en doen we nu alleen nieuwe projecten in Git.

[latka]

Hier een commentaar: ik gebruik het naast elkaar. Als je content (tekst, HTML etc) hebt in beheer bij iemand die nooit geleerd heeft wat een DAG is dan is SVN veel eenvoudiger uit te leggen en gebruiken.