Umstellung D7 auf D2010 Wie Versionsverwaltung organisieren?

[himitsu]

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.

[pertzschc]

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 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.

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

Ich bin weiterhin an Praxisberichten interessiert.

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 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).