Projekt auf ein anderes Laufwerk kopieren

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1342408)

Bei uns liegen die auch in einem anderen Verzeichnis. Die werden aber nur per Buildskript einmal erzeugt und nicht bei jedem Kompilieren eines Projekts :shock:.
Der Bibliothekspfad zeigt einfach auf die .dcu Dateien und das war es. In den Projekten werden die nur in die uses geschrieben, aber nicht in dem Projekt hinzugefügt.

Bibliotheks-Units nehme ich auch nicht direkt in die Projekte auf, sondern binde die über die Suchpfade ein. Ob man dazu die Sourcen oder nur die DCUs nimmt, hängt sicher vom eigenen Umfeld ab.

Bei mir sind aber alle Bibliotheken in dem Projekt oder im Über-Projekt eingebunden (als SubRepos), da ich in den verschiedenen Projekten halt oft unterschiedliche Versionen der Bibliotheken verwenden muss. Ich kämpfe heute noch mit den alten Projekt-Versionen, bei denen das noch über globale Pfade gelöst wurde, wenn ich die mal wieder anfassen muss. Da muss man nach dem Auschecken der Version erst seine Entwicklungsumgebung passend einrichten - häufig mit Laufwerksbuchstaben, die heute auf ganz was anderes zeigen als damals und somit auch nicht einfach geSUBST werden können.

[mm1256]

Zitat:

Zitat von Uwe Raabe (Beitrag 1342415)

Bibliotheks-Units nehme ich auch nicht direkt in die Projekte auf, sondern binde die über die Suchpfade ein.

Das habe ich bis vor ca. einem Jahr auch so gemacht und mich manchmal über Seiteneffekte gewundert. Das Problem kann sein, wenn man so wie ich überwiegend an einem einzigen großen Projekt arbeitet, ein größeres Update vor hat, und in diesem Zug noch Änderungen an den gemeinsam benutzten Units vornehmen muss.

Während dieser Umbauarbeiten möchte/muss ich aber auch Zugriff auf die alten Version (sowohl Projekt als auch alle Units) haben (benutze keine Versionsverwaltung) und dann schraubt man ständig an den Suchpfaden rum, was ich persönlich als lästig und fehleranfällig empfunden habe. Seit ich generell alle Units über absolute Pfade in die .dpr einbinde (Delphi macht das ja automatisch wenn die Units auf einem anderen Laufwerk oder nicht in einem Subordner des Projektes liegen) hab ich diesen Stress nicht mehr.

Aber, wie schon gesagt, das macht jeder auf die Art und Weise wie er am besten damit klar kommt. Hat alles seine Vor- und Nachteile.

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1342421)

Aber, wie schon gesagt, das macht jeder auf die Art und Weise wie er am besten damit klar kommt. Hat alles seine Vor- und Nachteile.

Richtig! Hier geht es ja auch gar nicht darum, wer was richtig oder falsch macht. Ich finde es sehr aufschlussreich hier verschiedene Arbeitsweisen und deren Gründe kennenzulernen. Das spart einem in manchen Fällen vielleicht selbst einen suboptimalen Weg einzuschlagen. Nur fürchte ich, daß wir dafür bald einen eigenen Thread aufmachen sollten.

[mm1256]

Ich glaube nicht, dass wir dafür von Daniel eines auf die Finger bekommen, denn es gehört doch irgendwie zum Thema. Denn, wenn man ein Projekt auf ein anderes Laufwerk umzieht, oder gar auf einen anderen Rechner, und die .dpr enthält z.B. ausnahmsweise absolute Pfadangaben, dann kann sich das ganz anders auswirken als bei Suchpfaden. Hat also doch irgendwas mit dem Thema zu tun. Abgesehen davon, wir bleiben ja anständig und sachlich :thumb:

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1342421)

Während dieser Umbauarbeiten möchte/muss ich aber auch Zugriff auf die alten Version (sowohl Projekt als auch alle Units) haben (benutze keine Versionsverwaltung) und dann schraubt man ständig an den Suchpfaden rum, was ich persönlich als lästig und fehleranfällig empfunden habe.

Keine Versionsverwaltung würde ich schon als unzumutbar empfinden. Ich verstehe ehrlich gesagt nicht wie man so ernsthaft arbeiten kann.
Dagegen ist die Fehleranfälligkeit von Suchpfaden noch die reinste Wonne. ;-)
Aber jedem das seine...

[mm1256]

sorry für OT

Zitat:

Zitat von jaenicke (Beitrag 1342427)

Keine Versionsverwaltung würde ich schon als unzumutbar empfinden. Ich verstehe ehrlich gesagt nicht wie man so ernsthaft arbeiten kann.

Ich ziehe bei jedem Master-Release (erscheint i.d.R. zum Jahreswechsel) die Ordner um, und gut isses. Abgesehen davon, wenn man bei einem Master-Release auch die Delphi-Version wechselt, was bei mir ja regelmäßig vorkommt, macht das die Versionsverwaltung auch stressfrei mit? In diesem Zug müssen ja sowieso die Suchpfade, Packages usw. geändert werden.

[Uwe Raabe]

Zitat:

Zitat von mm1256 (Beitrag 1342438)

Abgesehen davon, wenn man bei einem Master-Release auch die Delphi-Version wechselt, was bei mir ja regelmäßig vorkommt, macht das die Versionsverwaltung auch stressfrei mit? In diesem Zug müssen ja sowieso die Suchpfade, Packages usw. geändert werden.

Nein, das muss nicht so sein. Natürlich müssen die verwendeten Packages in der neuen Version vorhanden sein, aber das ist ja eigentlich Part der Delphi-Installation. Das gilt auch für die globalen Suchpfade. Die projekt-eigenen Suchpfade sind ja eh relativ und somit unabhängig von der Delphi-Version. In der Regel kann ich nach der Installation eines neuen Delphi mitsamt Design-Packages meine Projekte einfach darin öffnen und gut. Die Migration aller Projekte ist dann eine Sache von wenigen Minuten.

Bei den Dritthersteller-Komponenten habe ich meistens die Projektdateien und Projektgruppen so angepasst und Build-Gruppen erstellt, daß sie sich mit wenigen Klicks öffnen, compilieren und installieren lassen. Dann muss ich auch nicht erst auf die neue Version des Herstellers warten, was ja auch schon mal länger dauern kann.

In der Vergangenheit hatte ich immer wieder Schwierigkeiten mit Packages, die zu der Projektgruppe gehören und ausschließlich innerhalb dieser Gruppe benutzt werden. Dort war es mitunter sehr lästig, die Versionsabhängigkeit durchzuziehen. Aber da gibt es ja jetzt auch Abhilfe :)

[jaenicke]

Zitat:

Zitat von mm1256 (Beitrag 1342438)

Abgesehen davon, wenn man bei einem Master-Release auch die Delphi-Version wechselt, was bei mir ja regelmäßig vorkommt, macht das die Versionsverwaltung auch stressfrei mit? In diesem Zug müssen ja sowieso die Suchpfade, Packages usw. geändert werden.

Dafür gibt es bei uns eine Textdatei, in der festgehalten ist was installiert und eingestellt werden soll und gut ist es. Dann sind die ganzen Packages, JEDIs usw. installiert und die Projekte können einfach geöffnet und kompiliert werden.
Die passe ich bei einem neuen Release einmal an, in der Regel eine Sache von einer Stunde max. sobald die JEDIs da sind für die Version.

Will ich jetzt nachschauen was in einer Version von vor einem halben Jahr schief gegangen ist, kann ich einfach diese Version auschecken, per Batch die gemeinsamen Units neu erstellen und in der Version debuggen. So lässt sich dann ggf. ein Workaround oder Hotfix anbieten ohne auf die aktuelle Version aktualisieren zu müssen.

Dazu kommt, dass man ohne Versionsverwaltung nicht einmal sehen kann wann und warum eine bestimmte Zeile eigentlich zuletzt geändert wurde. Man kann einen Fehler also nur ggf. feststellen, kann aber nicht sehen, ob ein Fix evtl. an einer anderen Stelle Probleme macht, da man eine Änderung wieder zurücknehmen muss oder ähnliches. Man sieht ja nicht welche Änderungen mit anderen zusammenhängen.
Bei einer Versionsverwaltung kannst du einfach nachschauen warum jemand die Stelle geändert hat und was mit der Änderung noch zusammenhängt.

[mm1256]

Zitat:

Zitat von jaenicke (Beitrag 1342470)

Bei einer Versionsverwaltung kannst du einfach nachschauen warum jemand die Stelle geändert hat und was mit der Änderung noch zusammenhängt.

Für Teamarbeit und Gruppen ist natürlich eine Versionsverwaltung unerlässlich, da gibt es keine zwei Meinungen. Da ich seit etwa 13 Jahren Einzelkämpfer bin (seitdem beschäftige ich keine Programmierer mehr und erledige alles selber), ist also dieser "jemand der eine Stelle geändert hat" immer die selbe Person. Das ist wohl der Hauptgrund, warum mich die Versionsverwaltung bisher wenig interessiert hat.

[Sherlock]

Ich bin einer von der schusseligen Sorte. Wenn ich also mal wieder so unglücklich mit der Stirn auf die Tastatur geknallt bin, das der Code zwar compiliert, aber zur Laufzeit seltsame Dinge geschehen, die sich erst nach zwei Tagen offenbaren (*), bin ich ohne Versionsverwaltung aufgeschmissen.

Sherlock

(*) Das ist die einzige Fehlerquelle in meinen Programmen, ehrlich!