Moin Leute,

ich möchte einen TFS nach SVN migrieren inkl. vollständiger Historie und allen Quelltextzweigen. Dazu gibt es diverse Tools wie z.B. tfs2svn oder svnBridge.

Leider befinden sich bei dem zu migrierenden Projekt, einige Umlaute und Sonderzeichen in den Dateinamen. Aus diesem Grund stürzen die meisten Konverter ab oder arbeiten nicht vollständig (die oben genannten übrigens auch).

Für Ideen bin ich dankbar, ich schau mir zwischenzeitlich den Quelltext von beiden Projekten an und schaue ob ich ein Patch hin bekomme.

Rein Interessehalber: Was gibt es für Gründe für diesen Downgrade?

Zitat von Phoenix:

Rein Interessehalber: Was gibt es für Gründe für diesen Downgrade?

Würde mich auch interessieren.
Gerade wo doch die aktuelle Version von TFS um einiges günstiger geworden ist.

Zitat von Phoenix:

Rein Interessehalber: Was gibt es für Gründe für diesen Downgrade?

Naja Downgrade - nennen wir es Technologiewechsel.

Wir wollen alle Projekte aus allen Programmiersprachen einheitlich verarzten.
Da der Delphi, PHP und DotNet Bereich bei uns schon SVN nutzt, wollen wir nun auch die VB/VBA Leute ins SVN holen.
So können wir auch unsere Build bzw. CI-Prozesse vereinheitlichen.
Wir haben hier leider zu viele unterschiedliche Technologien.

Der Preis spielt bei uns keine Rolle.
Wir sind u.a. Gold Partner ISV.

Ihr habt euch das sicherlich gut überlegt, aber ein paar Sachen würde ich gerne in den Raum werfen...

• Ihr könntet sicherlich Delphi durch die SVN Bridge nutzen (also TFS Backend)
• TFS hat einen SCC Provider, der sich für die VBA'ler direkt in MS Access integriert. Da kriegt man als Außenstehender zwar Pickel auf'm Rücken wenn man das hört. Aber es ist alle Mal besser als das, was sie sonst machen würden.
• TFS hat extrem cooles Workitem Tracking mit komplett konfigurierbaren Workflows und Regeln für einzelne Transitions etc.
  Für SVN braucht man dafür Extra Software wie Team City, oder frickelige Halb-Lösungen wie Mantis
• Du bekommst dort schnieke Reports, die einem helfen vorauszusehen, wie lange z.B. die aktuelle Iteration denn noch braucht

Wenn man zu Mercurial oder Git wechseln würde, könnte ich das komplett nachvollziehen, da TFS nicht distributed ist. Aber SVN?

Wir haben uns halt gegen den TFS entschieden!
Zu viele Features und niemand kann hier damit (richtig) umgehen. Mit dem SVN schon und unsere Linux Leute können damit auch gut sprechen.

Der SCC Provider ist übrigens ein Blocking Typ, welcher auch gerade eingesetzt wird. Wir wollen aber auf "Merge" wechseln und da haben wir ein gutes Plugin gefunden, was das gewährleistet.

Also helft mir lieber das Problem zu lösen und verkauft mir nicht den TFS. Diesen hatten wir nun ca. 3 Jahre im Einsatz und kennen die Möglichkeiten.

Zitat von generic:

Wir haben uns halt gegen den TFS entschieden!

Schon klar, ich war halt nur etwas perplex...

Zitat:

Also helft mir lieber das Problem zu lösen und verkauft mir nicht den TFS. Diesen hatten wir nun ca. 3 Jahre im Einsatz und kennen die Möglichkeiten.

tfs2svn scheint wohl ein wenig vernachlässigt zu sein.
Aber es ist in .Net geschrieben, was es etwas leichter machen sollte da etwas zu frickeln.

Ich sah da auch Meldungen, dass chinesische Dateinamen nicht richtig rüberkommen. Vllt haben die da P/Invokes drin und nutzen die Ansi-Version der jeweiligen API.
Eine Suche nach "DllImport" könnte den Kreis der Verdächtigen einschränken.
Vllt. sind sie auch ganz ... PIEP... und nutzen IDbDataParameter mit DbType.AnsiString (halt irgendwas, was irgendwo an einer Stelle einen Ansi-Bottleneck darstellt).
Denn bei Unicode braucht es nur eine kleine Ansi-Stelle und alles ist im Rektum.
Vielleicht öffnen sie auch ein File als Utf16, welches Utf8 ist, und/oder anders rum. Du kannst dich ja schlau machen welche Encodings der TFS nutzt. Vllt ist der fixiert auf Utf8 und du kannst das Raten des Encodings damit leicht umgehen.

Mehr als solche grobe Schüsse ins Blaue habe ich leider nciht anzubieten. Viel Glück.