Software-update: Tortoisesvn 1.5.4

De ontwikkelaars achter Tortoisesvn hebben zaterdag versie 1.5.4 van hun programma uitgebracht. Tortoisesvn is een opensource Subversion-client en is bedoeld om versiebeheer mee uit te voeren. Versiebeheer is met name handig, zo niet onmisbaar, wanneer er met meerdere ontwikkelaars aan een project wordt gewerkt. Het programma integreert zichzelf als een shell extension in Windows en kan zelfstandig of in combinatie met een ide worden gebruikt. Versie 1.5.3 van Tortoisesvn wordt geleverd met Subversion 1.5.3 en bevat geen nieuwe features. Wel zijn er de nodige bugfixes aangebracht en deze versie heeft dan ook het stempel 'maintenance release' meegekregen. Hieronder is het changelog van deze release te vinden:

Changes:

• OpenSSL 0.9.8i with capieng enabled

Bugs fixed:

• Applying a patch where a context line had UTF-BOMs in it failed. (Stefan)
• Checking out multiple folders from the repository browser failed to unescape the target folder. (Stefan)
• If an url had special chars which needed escaping below the repository root, showing the log did not always work. (Stefan)
• Comparing two revisions sometimes did not work if the url didn't exist anymore in HEAD. (Stefan)
• Diffing/Blaming from TortoiseBlame on merged revisions did not work in certain situations. (Stefan)
• Unescape the target paths when exporting the changed files from the file diff dialog. (Stefan)
• the 'unversioned' overlay for folders didn't show up for some unversioned folders. (Stefan)
• After a "mine before theirs" or "theirs before mine" resolving action on the right pane in TortoiseMerge, the Undo would not undo correctly. (Stefan)
• Failures, even GPF in blame and log dialogs when specifying a revision range and a peg revision outside that range. (Stefan Fuhrmann)
• TortoiseMerge sometimes wrongly detected the encoding of files. (Stefan)
• If a merge conflicted due to added items the progress dialog did not count these correctly and the context menu missed items. (Tobias Sch?fer)
• TortoiseMerge could crash if the font size was set smaller than 8 pixels. (Stefan)
• When a cleanup failed, the error message didn't include the svn error string. (Stefan)
• /closeonend was ignored for the (un)lock command. (Stefan)
• The 'rename' context menu was not available for added files. (Stefan)
• Entering an URL before non-ascii text in the commit dialog corrupted the first chars of the non-ascii text. (Stefan)
• Blame from the repository browser ignored the diff options. (Stefan)

[break]

Versienummer	1.5.4
Releasestatus	Final
Besturingssystemen	Windows 2000, Windows XP, Windows Server 2003, Windows XP x64, Windows Server 2003 x64, Windows Vista, Windows Vista x64, Windows Server 2008
Website	The TortoiseSVN team
Download	http://tortoisesvn.net/downloads
Bestandsgrootte	17,80MB
Licentietype	GPL

Reacties (8)

[webfreakz.nl]

Mijn FireFox profile heb ik aan een SVN repository hangen, maar soms als ik die wil committen dan zijn er een aantal mappen, meestal van geupdate plugins, die obstructed zijn.

Daarna volgt een hoop geklooi met Clean-up / Update / etc om het weer goed te krijgen. Doe ik iets fout? Of zit er ergens een fout in TortoiseSVN?

[Nick_S]

Een versioned item wordt obstructed, als deze wordt weg gegooid en daarna opnieuw aangemaakt.
Volgens mij gebeurt dit alleen met directories. Hierin zit namelijk een .svn directory. Wordt deze .svn directory weg gegooid, dan ben je dus de koppeling met svn kwijt. (Deze directory zit dus niet alleen in je root, maar in elke directory in je working copy)

[J.J.J. Bokma]

Yup: het probleem onstaat doordat bij het inchecken van de directory zonder .svn ziet dat er al een directory met precies dezelfde naam al in de repository zit, kortom een obstructie.

Een oplossing is om de probleem directory te herbenoemen, een update te doen (krijg je een directory terug met dezelfde naam als de dir voor herbenoemen), en dan de bestanden uit de herbenoemde directory kopieeren in de directory teruggezet door svn, en dan die comitten. Je moet alleen wel goed opletten dat bestanden die gewist zijn in de herbenoemde directory ook wellicht gewist moeten worden in de directory die svn terug gezet heeft (het kan b.v. zijn dat een extensie niet meer goed werkt omdat er een oud bestand nog rondhangt).

Wat ik van git weet (en wat ik dus fout kan hebben), werkt dit niet met lokale hulp directories zoals svn. Mogelijk een oplossing.

Een andere oplossing kan zijn om de bestanden van je firefox directory te kopieren naar een directory die onder versiecontrole zit. Als je dat helemaal goed wilt doen, moet je ook deletes doorvoeren (via svn).

[Verwijderd]

Het lijkt me dat je Firefox dan niet goed hebt afgesloten. Dat hij, of een ander proccess mbt die plugins nog in je taakmanager blijft staan.

Anders kun je het misschien met iets als dit proberen.

[sroebert]

waarom zou je eigenlijk je firefox profile in een subversion repository gooien? neem toch aan dat je niet terug zou willen naar eerdere versies??

[Nick_S]

Ik denk vanwege dezelfde reden dat ik op m'n server heel /etc in een SVN repository heb gegooid.

Mocht je zelf wijzigingen aanmaken in bestanden, dan kun je deze inchecken en later weer terug. Mocht een update van software wijzigingen aanmaken, dan kun je deze ook controleren, en daarna inchecken.

Mocht ik een servercrash of een herinstallatie hebben, hoef ik alleen maar m'n /etc/ uit te checken en ben ik qua config weer up and running.

[webfreakz.nl]

Omdat het mij vooral om de incremental-backup gaat. Bij SyncBackSE kreeg ik het niet fatsoenlijk aan de praat, toen had ik nogsteeds uploads van 10+ MB op bestanden als urlclassifier3.sqlite en places.sqlite.

SynBackSE / SVN zijn voor mij niet verplichte programmas, mocht je andere tips hebben hoor ik het graag

[gertvdijk]

rdiff-backup