Strategie? - Gehören DPROJ-Dateien in die Versionsverwaltung?

[Ralf Kaiser]

Halli Hallo,

Wir stellen gerade eine größere Menge von Projekten auf die aktuelle Delphiversion um. Dabei werden alle Projekte auch so angepasst, dass sie sofort auf jedem Rechner kompilieren (Suchpfade mit Umgebungsvariablen, sonst nur relative Pfade usw.).

Bisher hat sich jeder im Team seine Projektgruppen selbst aus den DPK/DPR Dateien selbst zusammengestellt (es entstehen ja dabei die DPROJ). Die DPROJ-Dateien haben wir im Moment noch nicht in der Versionsverwaltung da sie, zumindest bisher, rechnerspezifische Pfade und Einstellungen enthalten haben. Mit dem neuen Konzept werden diese Dateien aber unabhängig vom Rechner, lediglich einige Umgebungsvariablen muss jeder bei sich einrichten/anpassen.

Leider ist es ja so, dass Delphi trotzdem immer wieder mal in die DPROJ-Dateien hineinschreibt, was dann die Versionsverwaltung mit eigentlich unnötigen Änderungen "verseucht". Wir verwenden GIT als Versionsverwltung, da könnte man die Dateien sogar mit "assume unchanged" behandelt und so, nach der ersten Einrichtung, für GIT "unsichtbar" machen. Ich bin mir allerdings noch nicht so ganz sicher welche eventuellen Probleme man sich damit einhandeln kann.

Wie haltet Ihr das mit DPROJ-Dateien in der Versionsverwaltung?

Ciao,
Ralf

[Bernhard Geyer]

dproj gehören ins CVS.
Wer eincheckt muss prüfen ob die getätigten Änderungen relevant sind oder ob sie verworfen werden können.

[bra]

DProj gehören auf jeden Fall in die Versionsverwaltung, da dort ja Pre/Postbuild-Events, Versionsinfos und speziell für die mobilen Plattformen noch alle möglichen relevanten Sachen hinterlegt sind.
Allerdings sollte die nicht jeder wild einchecken, sonst gibt's schnell Chaos.

Und leider werden die auch bei fast jedem Öffnen geändert, weil die IDE meint die Einträge mal wieder durcheinanderwürfeln zu müssen.

[himitsu]

Zitat:

Zitat von bra (Beitrag 1343042)

Und leider werden die auch bei fast jedem Öffnen geändert, weil die IDE meint die Einträge mal wieder durcheinanderwürfeln zu müssen.

Jo, weil die bei einigen Sachen gern die Reihenfolge unverständlich verändert.

Das könnte man nur Lösen, wenn die Vergleichsfunktion (DIFF) auf "XML" ausgelegt ist und das praktisch nach unsortiertem Inhalt vergleicht.
Aber eigentlich muß das genau auf "DPRO" ausgelegt sein, da manche Dinge eine "definierte" Reihenfolge haben.

[Ralf Kaiser]

Zitat:

Zitat von bra (Beitrag 1343042)

DProj gehören auf jeden Fall in die Versionsverwaltung, da dort ja Pre/Postbuild-Events, Versionsinfos und speziell für die mobilen Plattformen noch alle möglichen relevanten Sachen hinterlegt sind.
Allerdings sollte die nicht jeder wild einchecken, sonst gibt's schnell Chaos.

Das ist, zumindest bei uns, kein Problem. Die DPROJ-Dateien haben keinen Einfluss auf unseren Build-Prozess, der bei uns über den Jenkins-Buildsever erledigt wird. Da werden Versionsnummern gesetzt, der Build vorbereitet und nachbearbeitet.

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1343050)

Zitat:

Zitat von bra (Beitrag 1343042)

Und leider werden die auch bei fast jedem Öffnen geändert, weil die IDE meint die Einträge mal wieder durcheinanderwürfeln zu müssen.

Jo, weil die bei einigen Sachen gern die Reihenfolge unverständlich verändert.

Das könnte man nur Lösen, wenn die Vergleichsfunktion (DIFF) auf "XML" ausgelegt ist und das praktisch nach unsortiertem Inhalt vergleicht.
Aber eigentlich muß das genau auf "DPRO" ausgelegt sein, da manche Dinge eine "definierte" Reihenfolge haben.

Ich hab mir für D2007-DProjs ein kleines Tool gebaut, das das XML formatiert und grob sortiert. Den Rest kann man dann mit WinMerge und NotePad++ in den Griff kriegen.
XE6 formatiert DProjs zumindest schon mal selbst und auch sonst scheint es mir VCS-verträglicher.

[jaenicke]

Wer Quelltexte ohne Sichtprüfung jeder Änderung eincheckt, handelt ohnehin fahrlässig. Das ist genau der Weg, auf dem dann Debugmeldungen, Fehler oder andere unerwünschte Änderungen im Quelltext landen.

Insofern mag es zwar nerven, wenn die .dproj Dateien jedes Mal als geändert angezeigt werden, aber bei einem professionellen Ablauf beim Einchecken sollte es keine Probleme geben.

[hoika]

Hallo,
ich hbe mir angewohnt, die nicht automatisch ins Src-Verzeichnis einzuchecken,
sondern in einem eigenen nutzerbezogenen Verzeichnis.
Bei Änderungen wird das dann eingecheckt.
Wie oft hatte ein Merge der lieben Kollegen meine Projektdatei zerwürgt.

[Ralf Kaiser]

Zitat:

Zitat von hoika (Beitrag 1343073)

Wie oft hatte ein Merge der lieben Kollegen meine Projektdatei zerwürgt.

Genau das ist meine Befürchtung wenn ich die Dateien ins Repository übernehme (bei über 20 Leuten kann da sehr schnell was schief gehen...)

[hoika]

Hallo,
und es wird passieren ... ;)
Aber gesichert/versioniert müssen sie ...

[jaenicke]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1343074)

Genau das ist meine Befürchtung wenn ich die Dateien ins Repository übernehme (bei über 20 Leuten kann da sehr schnell was schief gehen...)

Da hätte ich dann echt Angst, wenn die Änderungen nicht geprüft werden vor dem Commit... :shock:
Wodurch unterscheiden sich denn versehentliche Änderungen in der .dproj von denen in anderen Dateien?

[Sir Rufo]

In einem Team sollte es einen geben, der den Source verwaltet.

Alle anderen erstellen nur einen Pull-Request der dann von dem einen geprüft und erst dann in das Haupt-Repository eingecheckt wird.

[Sherlock]

OT: Wieso heisst es eigentlich Pull-Request und nicht Push-Request? Die Änderung ist gemacht, und soll ins Hauptrepository geschoben werden. Da muß nichts mehr gezogen werden, das ist passiert, bevor die Änderung durchgeführt wurde.

Sherlock

[Aviator]

Zitat:

Zitat von Sherlock (Beitrag 1343082)

OT: Wieso heisst es eigentlich Pull-Request und nicht Push-Request? Die Änderung ist gemacht, und soll ins Hauptrepository geschoben werden. Da muß nichts mehr gezogen werden, das ist passiert, bevor die Änderung durchgeführt wurde.

:thumb: Würde mich auch mal interessieren. Oder war es nur ein Schreibfehler??? :roll:

[Sir Rufo]

Erklärung: Pull-Request

Pull = holen
Request = Anfrage

Also ist ein Pull-Request eine Anfrage an den Repository-Verwalter, diese Änderungen in das Repository zu holen.

Ein Push-Request wäre eine Anfrage des Verwalters, ihm doch die Änderungen zur Verfügung zu stellen, was dann über einen Pull-Request geht.

[Uwe Raabe]

Zitat:

Zitat von Sherlock (Beitrag 1343082)

OT: Wieso heisst es eigentlich Pull-Request und nicht Push-Request? Die Änderung ist gemacht, und soll ins Hauptrepository geschoben werden. Da muß nichts mehr gezogen werden, das ist passiert, bevor die Änderung durchgeführt wurde.

Das ist die Terminologie bei verteilter Versionskontrolle. Ich schicke dir einen Pull-Request, damit du dir die Änderungen aus meinem Repository in deines holst bzw. ziehst (pull). Das muss ich deswegen machen, weil ich selbst nicht in dein Repo pushen darf.

Wenn man mit Subversion und mehreren Branches arbeitet, wäre das wohl eher ein Merge-Request.

[Bernhard Geyer]

Ohne dproj-Datei wird es auch schwer werden automatisch Builds laufen zu lassen.
Also nix mit CI und Automatischen Tests.
Jedenfalls ist es mit einer dproj-Datei viel einfacher eine Exe zu bauen als früher mit dof+cfg-Dateien

[freimatz]

Zitat:

Zitat von Sir Rufo (Beitrag 1343079)

In einem Team sollte es einen geben, der den Source verwaltet.

Alle anderen erstellen nur einen Pull-Request der dann von dem einen geprüft und erst dann in das Haupt-Repository eingecheckt wird.

Bei Open Source vielleicht. Bei Ralf Kaiser handelt es sich wohl eher um ein Team. Da ist die Arbeit mit pull-Request wohl eher Steinzeit. Stand der Dinge ist wohl, dass Änderungen in einem Branch commited und gepushed werden. Wenn man in "master" will wird das markeirt und dann laufen auf der CI (bei Ralf Kaiser der Jenkins) durch macht builds, unit-tests, UI-Tests und erst wenn alls ok ist darf man in master.

[Sir Rufo]

@freimatz

Wo ist da der Unterschied?

Es geht um eine Instanz die entscheidet was in das Repo rein darf und was nicht. Ob eine natürliche Person oder ein entsprechender Prozess das macht ist doch unerheblich. Einer ist auf jeden Fall verantwortlich und der Rest darf nur lesen und Pull-Requests absetzen.

[Rollo62]

Zitat:

Da ist die Arbeit mit pull-Request wohl eher Steinzeit.

Dann gehört GitHub wohl endlich zum alten Eisen :wink:

Da geht es nur über Pull-Request ...

Rollo

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1343154)

Dann gehört GitHub wohl endlich zum alten Eisen :wink:

Da geht es nur über Pull-Request ...

Sicher? Kann ich dort nicht auch mehreren Entwicklern Schreibrechte auf ein Repo geben?

[Rollo62]

Im public Bereich nicht, soweit ich weiss.

Ich wollte auch nur mal solche "Pauschalaussagen" in Frage stellen.
PullRequest gehört dort zum Standardvorgehen, würde ich sagen.

Rollo

[Mikkey]

Um nochmal einen Beitrag zum Thema - von außerhalb des Tellers - zu bringen...

In der Microsoft-Welt lassen sich Projekte (z.B. ~.vcxproj) per Skript zu Solutions ~.sln zusammenfügen. Einstellungen der Solution, die unbedingt persisitert werden müssen, gibt es nicht.

Ich habe bisher den Inhalt der dproj-Dateien nicht genau angesehen, könnte mir aber gut vorstellen, dass etwas Ähnliches für deren Aufbau auch denkbar ist. Statt dieser Datei wird dann das Skript/eine entsprechende Kommandodatei eingecheckt.

[Sir Rufo]

Zitat:

Zitat von Rollo62 (Beitrag 1343161)

Im public Bereich nicht, soweit ich weiss.

Ich wollte auch nur mal solche "Pauschalaussagen" in Frage stellen.
PullRequest gehört dort zum Standardvorgehen, würde ich sagen.

Rollo

Das ist eine Frage der Berechtigung die man einstellen kann wie man lustig ist. Von Jeder darf alles bis keiner darf nix geht alles.