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

[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