SVN und DProj-Dateien

[xZise]

Zitat:

Zitat von PhilmacFLy (Beitrag 1041127)

Deswegen würd ich Git verwenden den Git kann 1a mergen. [...]

Was hat denn GIT mit einem merge zu tun? Ich meine er hat zwei Dateien die er mergen muss, ob die aus einem SVN oder GIT stammen sollte doch egal sein?

MfG
Fabian

[Uwe Raabe]

Zitat:

Zitat von xZise (Beitrag 1041235)

Zitat:

Zitat von PhilmacFLy (Beitrag 1041127)

Deswegen würd ich Git verwenden den Git kann 1a mergen. [...]

Was hat denn GIT mit einem merge zu tun? Ich meine er hat zwei Dateien die er mergen muss, ob die aus einem SVN oder GIT stammen sollte doch egal sein?

Das ist wohl nicht ganz richtig, da Git und Mercurial anders an die Sache herangehen, aber in diesem Fall ist das völlig irrelevant. Alle drei Systeme können nämlich nur vernünftig mergen, wenn die Dateien zeilenorientiert sind und das ist bei den droj-Dateien leider nicht immer der Fall. Hier wäre ein XML-Merger besser geeignet. Nur muss man den auch einbinden.

Nicht ganz so heftig, aber auch potentiell gefährlich ist das Mergen von DFMs. Auch da sollte ein passender externer Merger bessere Dienste leisten.

[hoika]

Hallo,

Zitat:

dann nehmt auch ein vernünftiges Clientwerkzeug, um Konflikte zwischen lokaler Arbeitskopie und dem SVN-Repository zu bearbeiten bzw. durch unverändertes Einchecken zu lösen. Das ist soweit mal unabhängig vom Thema "Chef".

Ich vergaß zu sagen, dass wir Tortoise benutzen.
Mir geht es darum, dass bei einer dproj-Datei (xml) kein normaler Mensch einen sinnvollen Merge machen kann,
und dass ich genau deshalb diese Dateien wie oben schon geschrieben,
"teilweise" aus dem Update raushaben will.


Heiko

[mjustin]

Zitat:

Zitat von hoika (Beitrag 1041265)

Mir geht es darum, dass bei einer dproj-Datei (xml) kein normaler Mensch einen sinnvollen Merge machen kann

In unserem Team checken wir dproj problemlos ein und aus, aber wir vermeiden Merges auch, indem wir lokale Änderungen einfach wieder reverten. D.h. alle arbeiten in der Regel mit den gleichen dproj Dateien. Funktioniert genausogut wie seit Jahren auch mit CFG und anderen Einstellungsdateien. Es erfordert allerdings, dass man eine einheitliche Entwicklungsumgebung (z.B. Pfade) hat.

Hoffen wir einfach, dass die dproj Dateien in zukünftigen Versionen (Delphi XE2 oder danach) Teamentwicklung besser unterstützen. Andere IDEs tun das ja auch schon länger ;)

[mjustin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1041241)

Hier wäre ein XML-Merger besser geeignet.

Subversion und Tortoise sind bei XML und DFM bei uns bisher völlig problemlos im Einsatz. Ich kenne auch keinen XML Merger, der da etwas besser macht - gibt es da tatsächlich typische Fehler, die regelmäßig auftreten?

[Uwe Raabe]

Zitat:

Zitat von mjustin (Beitrag 1041270)

Es erfordert allerdings, dass man eine einheitliche Entwicklungsumgebung (z.B. Pfade) hat.

Ich verwende in den dproj-Dateien nur relative Pfade und für die Delphi-eigenen die eingebauten Variablen. Damit kann ich ein Projekt in ein beliebiges Zielverzeichnis auf jedem Rechner auschecken und es funktioniert auf Anhieb. Ist auch für Branches ganz praktisch.

Die gemeinsam verwendeten Bibliotheken liegen dann als exernals in einem Lib-Unterverzeichnis.

[hoika]

Hallo,

Zitat:

gibt es da tatsächlich typische Fehler, die regelmäßig auftreten?

Lag viell. an Delphi.
Ich hatte die "conflict"-Datei (also die mit den >>>>>) einfach ignoriert und nicht geändert.


Heiko