Umstellung D7 auf D2010 Wie Versionsverwaltung organisieren?

[steffen_d]

Hallo,

wir möchten gerne unsere Projekte von Delphi 7 auf Delphi 2010 heben.
Ausserdem haben wir eine eigene Komponentensammlung, die per Package in jedes Projekt eingebunden wird, die ebenfalls auf 2010 gehoben werden muss.
Da wir einige Programme schon beim Kunden am Laufen haben, soll es nach wie vor möglich sein, diesen Versionsstand in Delphi 7 zu bearbeiten, z.B. bei Bugfixes.

Als Versionsverwaltung benutzen wir Subversion mit SmartSVN, als Bugtrackingsystem Mantis.

Unsere Überlegungen bis hierher:

Variante 1:
Wir legen im SVN ein neues leeres Repository an, und checken die Head-Revision des jeweiligen Projekts dort neu ein.
Vorteil:
Saubere Trennung von Delphi 7- und Delphi 2010-Code (durch getrennte Repositories).
Die Entwicklungsstränge unter Delphi 7 und Delphi 2010 sind völlig unabhängig.
Nachteil:
Die Historie geht verloren, die Revision beginnt wieder bei 0.

Variante 2:
Wir legen im selben Repository im SVN einen Branch für das Projekt für Delphi 2010 an.
Vorteil:
Die Historie bleibt erhalten.
Nachteil:
Aufgrund des gleichen Repositories kann es vorkommen, dass man, wenn man nicht aufpasst, die falsche Datei commited.

Variante 3:
Das Repository des jeweiligen Projekts wird kopiert.
In der Kopie wird in Delphi 2010 weiterentwickelt bzw. angepasst.
Vorteil:
Die Historie bleibt erhalten.
Saubere Trennung von Delphi 7- und Delphi 2010-Code (durch getrennte Repositories).
Die Entwicklungsstränge unter Delphi 7 und Delphi 2010 sind völlig unabhängig.
Nachteil:
Der Speicherverbrauch auf dem SVN-Server verdoppelt sich.

Welche Variante würdet Ihr uns empfehlen?
Macht es Sinn, die Komponentensammlung nach einer anderen Variante zu behandeln als die Projekte?
Oder habt Ihr eine ganz andere Idee?

Vielen Dank im Voraus!
Steffen

[himitsu]

Erstmal eine Frage:
Nutzt ihr irgendwelche "wilden" Pointer/Puffer-Speicherrumschiebereien?

Im Grunde könnte ihr jeden Code in Delphi 7, sowohl Delphi 2010 verwenden, wenn ihr an allen Stellen richtig trennt.

Da wo unbedingt ANSI verlangt ist (z.B. bei der Dateiübertragung oder der Speicherung), müßt ihr auch ANSI-Typen (AnsiChar, AnsiString, PAnsiChar) verwenden.

Ist unbedingt Unicode verlangt (auch in Delphi 7), so muß eben mit Unicode-Typen (WideChar, WideString, PWideChar) gearbeitet werden.

Da wo es je nach Delphiversion angepaßt sein kann, wird eben Char, String und PChar verwendet.


Vorallem wenn alles dynamisch (in Delphi 7 Ansi und in 2010 Unicode) sein soll/kann, dann gibt es keine Probleme, und man kann den selben Code sowohl in Delphi 7, als auch Delphi 2010 nutzen.
(nachdem man geprüft hat, daß auch wirklich nur Char, String und PChar im Code verwendet wurden)


Wenn ihr auch gleich mal einige "neue" Features von Delphi 2010 nutzen wollt, welche in D7 nicht existieren,
dann kommt ihr mit Variante 3 wohl besser:
> Code nur für D2010
> Code nur für D7
> Code welcher für beides Versionen ist

Ihr müßt dann allerdings bei einem Bugfix womöglich alles doppelt ändern. (jeweils in der D7- und der D2010-Version)


Gut, man könnte über Kompilerschalter auch alles in einer Version handhaben.
Kann somit an bestimmten Stellen, in den selben Units, jeweils einen versionsabhängigen Code verbauen.
Kann aber auch schlechter neue Compilerfeatures nutzen.

Zitat:

Da wir einige Programme schon beim Kunden am Laufen haben, soll es nach wie vor möglich sein, diesen Versionsstand in Delphi 7 zu bearbeiten, z.B. bei Bugfixes.

Ist es denn nicht möglich diese Versionen upzugraden ("jetzt" oder sobald mal ein Problem mit der alten Version auftritt) und alles komplett nur noch auf der neuen Version weiterzuentwickeln?

[shmia]

Ich würde Variante 1 wählen.
Durch die Umstellung von D7 auf Delphi2010 werdet ihr unbeabsichtigt einige Bugs einbauen,
da an vielen Stellen implizit unterstellt wird ein Char entspräche einem Byte.

Am Anfang werden viele Units angefasst werden müssen um sie D2010-kompatibel zu machen.
In den Formularen werden (unbeabsichtigt) neue Properties hinzukommen, so dass diese Units nicht mehr mit D7 kompiliert werden können!
Das ist das KO-Kriterium für die Idee, man könne mit einem Sourcecode in zwei Delphi Versionen leben.
In der Regel sind die Formulare lokal schreibgeschützt.
Also kann D7 auch nicht die Properties löschen, die es nur in D2010 gibt.

Ich habe versucht ein grösseres Projekt gleichzeitig mit D5 und D7 zu bearbeiten.
Keine Chance - D5 beklagt sich ständig über unbekannte Properties in Formularen.
Ok, man kann die Unit auschecken, die Properties löschen und wieder einchecken.
Aber wehe man checked die Unit wieder mit D7 ein, dann geht das Spiel von vorne los.

Ein guter Zeitpunkt um die gesamte Vergangenheit auszuradieren.
Ich würde auch alte Kommentare bzw. Datumsangaben in Kommentaren dabei entsorgen.

Die Bestandskunden bekommen in den älteren Versionen nur noch Bugfixes und kleine Verbesserungen und sollten dann wenn die D2010-Version stabil ist updaten.


PS:
Könntest Du wenn die Umstellung gelungen ist, dazu etwas schreiben?
Mir würde interessieren viele Units im Projekt sind, wieviele Units im Schnitt angepasst werden mussten,
wieviele Manntage das gedauert hat und wie lange es gedauert hat alle Bugs die durch D2010 entstanden sind zu beheben.

[mkinzler]

Zitat:

Ist unbedingt Unicode verlangt (auch in Delphi 7), so muß eben mit Unicode-Typen (WideChar, WideString, PWideChar) gearbeitet werden.

Wobei sich bei D2010 eher UnicodeString statt WideString anbietet

[himitsu]

Zitat:

Zitat von mkinzler

Zitat:

Ist unbedingt Unicode verlangt (auch in Delphi 7), so muß eben mit Unicode-Typen (WideChar, WideString, PWideChar) gearbeitet werden.

Wobei sich bei D2010 eher UnicodeString statt WideString anbietet

Das klappt aber nicht, wenn man es auch für Delphi 7 nutzen will.
(drumm hatte ich auch geziehlt den WideString genannt :stupid: )

[mkinzler]

Wenn schon getrennten Code dann richtig

[Chemiker]

Hallo,

Zitat:

Zitat von shmia

Könntest Du wenn die Umstellung gelungen ist, dazu etwas schreiben?
Mir würde interessieren viele Units im Projekt sind, wieviele Units im Schnitt angepasst werden mussten,
wieviele Manntage das gedauert hat und wie lange es gedauert hat alle Bugs die durch D2010 entstanden sind zu beheben.

das würde mich auch interessieren.

Bis bald Chemiker

[H4ndy]

Hatten das gleiche "Problem".

Wir haben vorher mit Microsoft Visual SourceSafe gearbeitet und im Zuge der Delphi-Migration auf SVN+Redmine (mit TortoiseSVN als lokales Werkzeug und dem TortoiseSVNDelphi-Plugin) umgestellt. Wir haben uns fuer Variante 1+3 entschieden.

Unsere alten SourceSafe-DB haben wir abgeschlossen. Dann die letzte Revision genommen und ins SVN gepackt als Trunk.
Dann wurde von diesem neusten Stand (nennen wir es Release 4.2.0) ein Branch 4.x angelegt, welcher fuer D7 zur Weiterentwicklung genutzt wird, falls Bugfixes, etc. anfallen. Fertige Releases bekommen einen Tag oder neuen Branch (z.B. 4.2.1).

Im Trunk haben wir dann mit dem 4.2.0-Source die Migration auf D2010 vollzogen, welche dann am Schluss im Release v5 enden soll (mit neuen Features, etc.). Auch hier: fertige Releases werden als Tag oder Branch "abgelegt".

Nachteile:
- History indirekt verloren (kann im SourceSafe noch lesend abgerufen werden)
- Bugfixes aus dem Trunk muessen in den 4.x-Zweig gemergt werden (und umgekehrt)
- "Hoher" Speicherplatzverbrauch (ist aber zweitrangig)
Vorteile:
- Klare Trennung der alten D7- und zukuenftigen D2010-Version.
- Kein Merge mehr notwendig, wenn Support fuer die D7-Version ausgelaufen ist (und somit dann D2010 alleinige IDE wird)

Unser Projekt umfasst im Moment "nur noch" etwas um die 1100 Units (haben im Zuge der Umstellung aufgeraeumt und viele Altlasten geloescht), anpassen mussten wir gefuehlt fast alle. Die Haupt-Migration auf D2010 (Projekt lauffaehig uebersetzen und alle Hints/Warnings entfernen) hat ueber 1 Monat benoetigt (mit ca. 8 Leuten Vollzeit), dazu kam dann noch der Funktionstest, ob alles noch genauso funktioniert wie vorher, welcher aber nahtlos mit der Weiterentwicklung einherging, daher kann ich hier keine Zeitabschaetzung geben, ich schaetze aber, dass ca. 6 Wochen fuer die gesamte Migration verloren gingen.

[himitsu]

Zitat:

Zitat von Chemiker

das würde mich auch interessieren.

Gib mir 'nen Tag Zeit. :angel2:

Die Anzahl der Units ist grundsätzlich erstmal egal.

- es kommt auch noch darauf an, ob derjenige schon weiß, auf was man achten muß
oder ob man erstmal jedes Problemstelle über einen Fehlertest, Aufgrund eines Fehlers, suchen muß

- dann kommt es auch darauf an, was diese Units machen
also wieviele Problemstellen es überjaupt geben könnte

- und wie bisher gearbeitet wurde
z.B. AnsiChar/AnsiString/PAnsiChar mit Char/String/PChar in Delphi 7 vermischt hat und womöglich auch noch irgendwelche Pointer-Operationen vorgenommen werden, dann gibt es womöglich unter D2010 massive Probleme.
Wurde aber überall genau der Typ verwendet (AnsiString/WideString), welcher expoizit nötig ist und unabhängig davon an anderen Stellen, wo der Typ egal ist, der String verwendet, dann gibt es womöglich überhaupt keine Probleme und alles funktioniert sofort.

- Wenn man z.B. nur String, PChar und Char verwendet hat und man Speicherblöcke in Chars, statt Byte bemißt oder schon eine Anpassung, ala *SizeOf(Char), vorgesehn hat, dann sollte eine Umstellung keinerlei Probleme bereiten.

[H4ndy]

Zitat:

Zitat von himitsu

[...]Wurde aber überall genau der Typ verwendet (AnsiString/WideString), welcher expoizit nötig ist und unabhängig davon an anderen Stellen, wo der Typ egal ist, der String verwendet, dann gibt es womöglich überhaupt keine Probleme und alles funktioniert sofort.

- Wenn man z.B. nur String, PChar und Char verwendet hat und man Speicherblöcke in Chars, statt Byte bemißt oder schon eine Anpassung, ala *SizeOf(Char), vorgesehn hat, dann sollte eine Umstellung keinerlei Probleme bereiten.

Waehre schoen gewesen, aber das ist das tolle an recht alter, historisch gewachsener Software: Klappt leider nicht immer wie gewuenscht :mrgreen:

Unser Hautpproblem waren Pointer-Frickelleien und eben die generischen Typen statt der gebrauchten (und das Laden/Speichern/Verschieben dieser, Stichwort "Length"). Mittlerweile haben wir durch die Migration aber viel gelernt und Beruecksichtigen diese Probleme nun aktiv bei der Neu-/Weiterentwicklung (wo auch Herr Bernd Ua nicht ganz unschuldig dran ist, sein Workshop auf den Entwicklertagen '10 zum Language Update war sehr hilfreich fuer unsere Migration).

[himitsu]

Zitat:

Zitat von H4ndy

Mittlerweile haben wir durch die Migration aber viel gelernt und Beruecksichtigen diese Probleme nun aktiv bei der Neu-/Weiterentwicklung ...

Das hoffe ich, denn wir könnten quasi kurz vor UCS4 stehen. :angel:

[pertzschc]

Zitat:

Zitat von mkinzler

Wenn schon getrennten Code dann richtig

Welche Lösung würdest Du also preferieren?

Wie sieht Ihr denn die Aspekte mit der neubeginnenden Revisionsnummer (Variante 1) und der verbleibenden Historie (Variante 3).

Neubeginnenden Revisionsnummer (Variante 1):
Wir sehen halt das Problem, dass unsere Commitnachrichten im Mantis-System an behobenen Meldungen bei Variante 1 wieder bei 1 losgehen und man innerhalb des selben Produktbereiches in Mantis dann nicht mehr weiss, auf welches Repository sich eine Revisionsnummer bezieht.

Verbleibende Historie (Variante 3):
Wir schätzt Ihr das ein? Sollten die Commit-Messages und die Historie der einzelnen Units erhalten bleiben für spätere Wartung?

Gruß,
Christoph

[H4ndy]

Warum nicht den aktuellen Stand in einen eigenen Branch packen, welcher fuer die D7-Entwicklung genutzt wird (Revision bleibt erhalten) und im Trunk die Migration durchfuehren? Dann muesste ja mit den Revisionen alles gleich bleiben wenn ich SVN richtig verstehe. In im D7-Branch kann man sich ja noch die volle Log-History abholen, wenn man "Stop on Copy/Rename" nicht aktiviert. Wenns Bugfixes im D7-Zweig gibt, sind dann halt im Log groessere Rev.-Spruenge drin, da man nur selten daran arbeitet. (Arbeite noch nicht lang mit SVN, korrigiert mich wenn ich falsch liege).

[mjustin]

Zitat:

Zitat von H4ndy

Warum nicht den aktuellen Stand in einen eigenen Branch packen, welcher fuer die D7-Entwicklung genutzt wird (Revision bleibt erhalten) und im Trunk die Migration durchfuehren?

+1 ... das ist die Variante mit den wenigsten Brüchen und ohne doppelten Speicherbedarf. Man hat alle Revisionen (bloß nichts wegwerfen was man später eventuell braucht), und kann neue Features zwischen trunk und branch mergen.

[steffen_d]

Hallo und erstmal vielen Dank für die bisherigen Beiträge.

Wir haben hier nach wie vor noch keine Entscheidung getroffen.
Bei ersten Tests ist mir aufgefallen, dass ich wohl überall Char mit AnsiChar und pChar mit pAnsiChar ersetzen muss, damit es ordentlich compiliert.
An einigen Stellen, vor allem in "Uralt-Code", werd ich wohl grundsatzlich was umstellen müssen. :coder2:

An einer problematischen Pointeroperation bin ich noch nicht vorbeigekommen, aber das kann sich ja noch ändern. :mrgreen:

Ich bin weiterhin an Praxisberichten interessiert. :dp:

Vielen Dank und viele Grüße
Steffen

[mkinzler]

Wobei du den Weg, auch in neuen uncodefähigen Delphiversion nur "Ansi" zu nehmen, überlegen solltest.

[himitsu]

Zitat:

Zitat von mkinzler

Wobei du den Weg, auch in neuen uncodefähigen Delphiversion nur "Ansi" zu nehmen, überlegen solltest.

Klar könnte man auch an vielen Stellen einfach alles auf Ansi festlegen, womit der alte Code problemlost weiterlaufen könnte,

aber hier gibt es ein Problem:
- die GUI und viele StringRoutinen-/Klassen gibt es nur noch als Unicode (z.B. TStringList/TStrings), so daß man dort garkein Ansi umsetzen kann.
(für die Alten Ansi-Delphi gibt es immerhin ein paar externe Unicode-Komponenten, aber für die neuen Unicode-Delphis gibt es keine Ansi-Versionen ... gut, hier könnte man vielleicht die Alten TNT-UnicodeControls verwenden und daraus eine AnsiControls-Ansammlung erstellen)

Aber hier würde ich dann eher zu Delphi 2007 raten, wenn man beim Ansi bleiben will und ab D2009 lieber vieles auf Unicode umzustellen (ist einfach einfacher so).