SVN: DFM-Merge oder "die üblichen Verdächtigen"

[hoika]

Hallo #,

mal wieder habe ich zusammen mit Kollegen an der gleichen DFM gearbeitet,
Auto-Merge ging schief, mal wieder (TBitButton ist ein Fluch).

Also Winmerge geschnappt und von Hand gemergt.

Dabei etwas übersehen. -> Plautz

Die Problematik ist ja bekannt.
Nur was soll man machen ?

Da es sich um die Hauptforms handelt und auch am Wochenende was gemacht wird,
fällt ein "Sperren per Zuruf" flach.

Heiko

[ele]

Das Automerge lässt sich - zwar etwas umständlich - deaktivieren.

Dann musst du das Mergen einfach selber übernehmen.

[Lemmy]

Hi Hoika,

ich meine, dass SVN auch das sperren von Dateien unterstützt, dazu müsste man aber etwas Aufwand betreiben und vor einer Änderung immer erst schauen ob eine Sperre da ist und sich diese dann holen.

Aufgrund vergleichbarer Erlebnisse würde ich bei Entwicklung in einem Team eher zu Mercurial tendieren, da dort eben dieses Mergen wesentlich besser funktionieren soll:

http://hgbook.red-bean.com/read/how-...-get-here.html

Wobei der Einsatz der Explorererweiterung wohl nicht empfehlenswert sei.

Grüße

[Bummi]

Jetzt ist ja eh leider zu spät, aber sonst könnte man ja vor dem manuellen Merge die zu mergenden Dateien einmal in einen Sicherungsordner kopieren, wenn schief gegangen ist nochmals mit den Sicherungen versuchen.

[Phoenix]

Du kannst im SVN tatsächlich einen lock auf das File setzen. Ich habe damit allerdings noch nie gearbeitet.

[hoika]

Hallo,

nützt mit leider nichts

lock -> am Wochenende arbeiten mehrere an der DFM
Mercurial -> kann auch keine DFM's anständig mergen
Sicherheitsordner -> machen wir bereits
Mergen einfach selber übernehmen -> genau da passierte ja der Fehler

;(


Heiko

[Lemmy]

Hi,

Zitat von hoika:

lock -> am Wochenende arbeiten mehrere an der DFM

dann solltet ihr an eurer Kommunikation arbeiten. Ich kann mir nicht vorstellen, dass mehrere Entwickler an einem Wochenende massive (große) Änderungen an einem Hauptformular vornehmen, wenn doch, dann solltet Ihr das Ding auftrennen (z.B. über Frames). Und wenn es um das Einfügen eines MenuItem oder Buttons geht, da bin ich schon oft hergegangen und habe meine Änderungen gesichert, das von den anderen geänderte Formular geholt und die Änderungen händisch übertragen (neuer Menuitem und Event kopiert).

Zitat von hoika:

Mercurial -> kann auch keine DFM's anständig mergen

Danke für die Info.

GRüße

[HeZa]

Zitat von hoika:

mal wieder habe ich zusammen mit Kollegen an der gleichen DFM gearbeitet,
Auto-Merge ging schief, mal wieder (TBitButton ist ein Fluch).

Also Winmerge geschnappt und von Hand gemergt. Dabei etwas übersehen. -> Plautz

Die Problematik ist ja bekannt. Nur was soll man machen ?

Da es sich um die Hauptforms handelt und auch am Wochenende was gemacht wird,
fällt ein "Sperren per Zuruf" flach.

Analysiert warum ihr immer gleichzeitig an der Hauptform arbeiten müsst und extrahiert die dazu führenden Gründe in separate Units. Z.B könntet ihr visuelle Bereich in einer eigen Form (oder Frame wenn man diesen dynamisch einblendet) programmieren und diese dann nur in der Hauptform einblenden (wenig Code-Änderungen, die sich leicht mergen lassen). Müsst ihr oft gleichzeitig das Menü oder eine Actionlist erweitern, könnte Ihr eine Methode schreiben mit der man Menüpunkte oder Actions in der Hauptform registrieren lassen kann.

Minimiert die Zeit die Ihr in der Hauptform programmiert. Z.B. indem ihr euren Code bzw. eurer Design erst in einer anderen Unit erledigt. Bevor ihr dann in den Trunk eincheckt holt ihr euch die aktuelle Version des Hauptform, verschiebt eure Änderungen hinein und commit anschließend sofort eure Änderungen.

[stahli]

Angenehmer als Frames finde ich inzwischen eingebettete Formulare:

Delphi-Quellcode:

procedure TFormCompetitors.FormCreate(Sender: TObject);
begin
  FormClubsControl.ManualDock(TabSheetClubsControl, nil, alNone);
  FormClubsControl.Align := alClient;
  FormClubsControl.Show;

  FormClubsOverview.ManualDock(TabSheetClubsOverview, nil, alNone);
  FormClubsOverview.Align := alClient;
  FormClubsOverview.Show;
end;

Die Formulare sind "schön eigenständig" und werden zur Laufzeit dynamisch z.B. in ein TabSheet eingebunden.

Euer Problem würde sich dadurch sicher deutlich reduzieren.

(Wobei ich das Konzept svn immer noch nicht so richtig verstanden habe - kennt jemand vielleicht ein möglichst deutsches Demovideo, welches auch für den svn-Einsatz im RAD-XE taugt? Die XE-Preview 1 reicht mir zum Verständnis noch nicht.)

[HeZa]

Zitat von stahli:

Angenehmer als Frames finde ich inzwischen eingebettete Formulare

Ich bin auch ein Fan von eingebetteten Forms, wenn man Frames allerdings dynamisch einbettet, haben sie fast keine Nachteile mehr.