SVN und DProj-Dateien

[hoika]

Hallo #,

in DProj-Dateien werden ja diverse Projekteinstellungen gespeichert (xml).
Sinn macht es, die im SVN mit zuspeichern.

Dumm nur, dass wenn 2 Leute am selben Projekt "rumgefummelt" haben
und ein SVN-Update machen, dass SVN anfängt die Änderungen zu mergen.

Leider kommt Delphi mit der gemergten Datei nicht wirklich zurecht *wunder* ;)

Aber wie geht man mit solchen Dateien um.
Es betrifft auch die Res-Dateien (ja ich weiss, werden wieder erzeugt, sollen aber nicht).

Mein Ansatz ist jetzt bisher, ein Unterverzeichnis "Einstellungen" anzulegen und die dorthin zu "retten".
Danach noch eine Anweisung an die Mitentwickler, bei Problemen die Dateien von dort zu holen.


Wie geht ihr mit solchen Dateien im SVN um ?

Danke


Heiko

[Bernhard Geyer]

Zitat:

Zitat von hoika (Beitrag 1040975)

Leider kommt Delphi mit der gemergten Datei nicht wirklich zurecht *wunder* ;)

Was kommt dabei raus? Ich tipp darauf das SVN entsprechende marker setzt das eine Händiesches Auflösen des Mergeergebnisses nötig ist.

[hoika]

Hallo,

am besten soll SVN die Finger von lassen.

Ignore geht aber nicht, weil im Repository soll es schon drinbleiben.
(Ignore wirkt sich nur auf nicht versionierte Dateien aus).

Ein Teufelskreis ;)


Heko

[Sherlock]

Kann man das Mergen in SVN nicht abschalten? Hui, bin ich froh, daß wir auf JediVCS setzen ;)

Sherlock

[hoika]

Hallo,

also soweit ich weiss nicht ...


Heiko

[fkerber]

Hi!

Normal sollte das Ergebnis eines erfolgreichen Merge-Prozesses aber der Version des eincheckenden entsprechen. Wenn also eine gültige Datei eingecheckt wird, sollte auf der anderen Seite auch eine gültige rauskommen.

Das Ganze geht halt schief, wenn auch auf Empfängerseite was geändert wurde, dann klappt das Merging nicht und es werden >>>> in die Datei eingefügt, um den Konflikt (bzw. die 2 Versionen) abzugrenzen.


Liebe Grüße,
Frederic

[hoika]

Hallo,

schon klar. Ist aber eine "interne" Delphi-Datei.
Mit den << >> kommt Delphi aber nicht klar.

Meine Lösung ist jetzt:

- Res und DProj retten (auf allen Rechnern)
- Res und DProj aus dem Repository raus (Delete and Add To Ignore List)
- Update auf allen Rechnern
- Res und DProj wieder reinkopieren
- Verzeichnis Einstellungen anlegen und dort die Res und DProj parken, das Verzeichnis kommt auch in SVN


Heiko

[H4ndy]

Es darf halt immer nur einer in den Projektdateien rumfummeln. Wenn ein Merge mal schief geht einfach ein Revert zur HEAD-Revision machen und schon hat man die letzte Version ausm Repo.

[blackfin]

Huh? SVN merget doch eine .dproj nicht automatisch? Das ist mir noch nie passiert, es kennt den Typ von .dproj doch gar nicht und behandelt es erstmal wie eine binäre Datei, ausser du hast es auf svn:eol-style=native oder so in der config gestellt?

Oder zeigt es nur an "conflicted" beim update? Dann kannst du die Datei ja anwählen und sagen "resolve by using mine / theirs"

[hoika]

Hallo,

Zitat:

Oder zeigt es nur an "conflicted" beim update? Dann kannst du die Datei ja anwählen und sagen "resolve by using mine / theirs"

Stimmt.

Aber mein Chef will nicht "anklicken" und nachdenken (vor allem bei jedem Update !).
Anklicken und los.

Aber ich höre gerade, bei CVS (war hier früher im Einsatz) musste man auch solche Klimmzüge machen.


Heiko

[mjustin]

Zitat:

Zitat von hoika (Beitrag 1041017)

Hallo,

schon klar. Ist aber eine "interne" Delphi-Datei.
Mit den << >> kommt Delphi aber nicht klar.

Was sind das für << >>? Vermutlich sind das die Konfliktmarker, und den Konflikt kann / sollte man in TortoiseMerge zuerst lösen bevor man das Projekt bearbeitet.

Mal schaun, wie Delphi XE das Problem in der Subversion Integration angehen wird :)

Cheers,

[hoika]

Hallo,

Zitat:

bevor man das Projekt bearbeitet

Ändere ich zum Test mal eine Einstellung, "verteilt" SVN per Mach-Kaputt-Merge
das an alle anderen ... ;(


Heiko

[PhilmacFLy]

Deswegen würd ich Git verwenden den Git kann 1a mergen. Nur sollte man da dann auch Files ignorieren. Hier mal mein gitignorefile

Code:

*.dcp
*.cbk
*.dcu
*.identcache
*.local
*.dsk
*.~dsk
*.exe
__history

Kannst du die entsprechenden Dateien nicht aus dem Repro wieder entfernen?

[hoika]

Hallo,

Zitat:

Kannst du die entsprechenden Dateien nicht aus dem Repro wieder entfernen?

Klar kann ich, aber ...

Checke ich für einen neuen Rechner aus, fehlen mir genau diese Dateien.
In der dproj stehen aber u.a. die Warnings-Settings.
Die Standard-Einstellungen ballern mir z.B. bei TMS 10k Warnings wegen unsicherem Code (Zeiger-Operationen).

Unter InnoSetup gibt es ein "Kopiere Datei nur, wenn nicht vorhanden".
Sowas bräuchte ich auch bei SVN, also kein Merge, wenn Datei vorhanden. *SVN-Quellcode* ;)

Einzige Lösung, die mir einfällt:
- warten auf "ignore merge", OK, *wart* ;)

- Dateien löschen (vorher retten ..), damit sind sie aus dem Repository raus
- zusätzliches Verzeichnis "Settings" mit ebend diesen Dateien (res, dproj)


Heiko

[fkerber]

Hi!

Naja, wenn du im Prinzip immer die Version behalten willst, die du hast (wenn du eine hast) dann genügt es doch, beim Conflict zu sagen: Resolve->Take mine - oder sollte auch das automatisiert werden?


Grüße,
Frederic

[himitsu]

Zitat:

Zitat von hoika (Beitrag 1041166)

In der dproj stehen aber u.a. die Warnings-Settings.

Die müßte man auch per Code sezten können.

Delphi-Quellcode:

{$WARN ...}

oder

Delphi-Quellcode:

{$WARNINGS ...}

.

(PS: wer keinen bösen Code schreibt wird auch nicht verwarnt :zwinker: )

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1041166)

Unter InnoSetup gibt es ein "Kopiere Datei nur, wenn nicht vorhanden".
Sowas bräuchte ich auch bei SVN, also kein Merge, wenn Datei vorhanden. *SVN-Quellcode* ;)

Wenn Datei nicht vorhanden, was soll denn dann bitte gemerged werden?

Man kann natürlich auch in SVN mit Locks arbeiten - mit allen dazugehörenden Problemen...

[hoika]

Hallo,

viel Traffic hier ;)

Zitat:

beim Conflict zu sagen: Resolve->Take mine - oder sollte auch das automatisiert werden?

Genau, jedesmal zu klicken, missfällt dem Chef (zurecht)

Zitat:

In der dproj stehen aber u.a. die Warnings-Settings.

Ich meinte Warnungen wie "Bibliotheken" (so hiess dass unter D2007).
Damit konnte man durch Entfernen der entsprechenden CheckBox Units, die über den Lib-Pfad gefunden wurden,
z.B. von der Anzeige der Warnung "unsicherer Code" ausschließen.

Standard ist aber "checked"

Zitat:

Wenn Datei nicht vorhanden, was soll denn dann bitte gemerged werden?

Beim Update soll folgendes passieren
Wenn Sie nicht vorhanden ist -> Kopieren (so wie jetzt auch)
Ist die Datei lokal bereits vorhanden, soll überhaupt nichts passieren,
also weder merge noch Hinweis noch sonstwas.


Ist aber egal, man kann nicht alles automatisieren.


Heiko

[Uwe Raabe]

Ach ja, man kann zur besseren Kontrolle über das Merging auch externe "Merger" einsetzen. Stichwort "External diff3".

[pertzschc]

Zitat:

Zitat von hoika (Beitrag 1041186)

viel Traffic hier ;)

und auch einiges Durcheinander :shock:

Wenn Ihr für die Entwickler SVN als Sourceverwaltung einsetzt, 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". Ein sehr vernünftiges Tool dafür ist SmartSVN (oder auch TortoiseSVN).

Was man vernünftig automatisieren kann, sind Builds der Projekte auf einem separaten Rechner. Dazu kann man z.B. ANT-Skripte benutzen und vorher mit "svn update" immer die neueste (sogenannte HEAD) Revision aus dem Repository auf den lokalen Clientbereich auschecken und dann damit das Projekt kompilieren & bauen lassen.

Viele Grüße,
Christoph

[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