Team Development - Versionskontrolle - GIT

[Andrew Harder]

Hallo,

Gestern habe ich die Zeit gefunden das im Designer 8.5.3 hinzugekommene 'Team Development' auszuprobieren.
Ich habe mich hierbei für GIT entschieden. Benutzt habe ich die grafische Benutzeroberfläche die mitgeliefert wurde.

Betriebssystem: Windows 8 Prof.
Designer: 8.5.3 (ohne Fixpacks)
GIT: Git-1.8.0-preview20121022.exe

Meine anfängliche Begeisterung ist aufgrund einiger Dinge aber in Entsetzen umgeschlagen.

Ersten Master erstellt, eine Änderung in einem Script Agenten erstellt und im grafischen Benutzertool wollte ich mit die Änderungen ansehen die ich gemacht hatte.
1. Kein Update in den lokalene Dateien, Google bemüht, doch welche Einstellung in den Prefences genau ich da machen soll ist mir ein Rätsel.
Sei es drum, halt manuell im Kontextmenue des Designers upgedatet.
2. Änderungen angesehen. Alles drinne... ausser halt der Quelltext... Wie soll ich da Änderungen später nachvollziehen können?
3. Nächste Änderung gemacht. Die Änderung zur übertragung markiert und mit einem Kommentar übertragen. Dannach im Baum auf den vorherigen Stand zurückgestellt. Klappt in GIT. Den Designer juckt das aber überhaupt nicht, da kann ich snycen bis zum jüngsten Tag.

Habe ich da etwas falsch verstanden, bin ich da irgendeinem Bug aufgesessen, fehlt mir ein Plugin damit das funktioniert, oder ist das ganze von IBM nur als Designstudie vorgesehen?

[pram]

Ich verwende SVN (allerdings ohne Plugins)
Habe dazu ein "on disk project" eingerichtet.
Damit sich die Änderungen automatisch syncronisieren, muss unter Preferences -> Domino Designer -> Source Control die entsprechenden Haken setzen.

Ich muss dazu sagen, für mich dient das eher der Code-Review, als Versionskontrolle kann man das Ganze eher schlecht gebrauchen, weil:
- Es werden m.E. zu viele unnütze Metadaten übertragen (lastModified-Infos)
-> Nach einem Recompile hat sich in praktisch JEDER Datei der lastmodified-by Wert geändert
- Ein Sync from Disk to NSF endet je nach Gestaltungselement oft in einem Chaos (DXL ist nicht 100%ig round trip fähig, Ansichten sind relativ problemlos, bei Masken/Teilmasken gehen manchmal diverse Formatierungen etc. verloren, teilweise ganze Events in Buttons/Hotspots, bei Gliederungen geht der Zustand (auf/zugeklappt) verloren)
- Script-Libraries werden (gottseidank) als ".lss" und ".metadata" exportiert. Die ".metadata" enthalten die sich dauernd ändernden Timestamps, so dass man durch svn-igonore:*.metadata zumindest im Code-Bereich wirklich nur die Änderungen mitbekommt, die auch tatsächlich Änderungen am Code sind.

Ich vergleiche deshalb eigentlich nur die Lotusscript-Änderungen bei der Entwicklung.
Den Check-In erledige ich mit Tortoise-SVN, hier kann man durch Editieren der On-Disk Lotusscript-Files (andere fasse ich aus o.g. Gründen nicht an) auch Änderungen wieder rückgängig machen, diese importiert der Designer dann auch wieder.

Bei XPages mag die Sache vielleicht wieder anders aussehen, da hier überwiegend XML bzw. normale Textdateien das Design beschreiben

Gruß
Roland

[Andrew Harder]

Danke für Deine Antwort, jetzt sehe ich einiges wieder klarer.

Source Control: Alle 4 Optionen sind bereits angehakt.
Der Hinweis mit den LSS war aber super.

Bei den LSS Dateien sehe ich die Änderungen und Rückgängig machen geht auch!
Dies scheint einer der Teile zu sein wo das ganze funktioniert.

Mit Notes 9 wird alles besser

[flaite]

Auf diesem Blog scheinen einige interessante Informationen zu stehen:
http://jinoch.cz/

Ich selbst stell auf git um, hab jahrelang svn benutzt und das ist auf der Arbeit immer noch.
Lern das erstmal auf der Kommando-Zeile bevor ich die gute Eclipse und Netbeans Integration benutze.
Auch gestützt mit dem Buch mit den Segelbooten auf dem Cover bei Amazon, muss man aber nicht. Ich bin so.

Das Konzept IST besser als svn. Allein schon, dass es nicht diese nervenden svn directories auf den Client verteilt. Git errechnet sich hashes aus den Dateien und vergleicht so.

Mit dem nicht 100% roundtripfähigen dxl bleibt natürlich, aber das läßt sich möglicherweise eingrenzen.
 

[eknori]

Im Unternehmen setzen wir SVN ein. Und das wird auch so bleiben. Wir haben Tonnen von C/C++ Code, der über Jahre hinweg gewachsen ist und der in SVN verwaltet wird.

Als Client setze ich Tortoise ein. Ich brauche diesen One-Klick Blödsinn nicht so unbedingt und kann daher auf ein funktionierendes Plugin für die Anbindung des DDE an SVN gut und gerne verzichten.

Ersten Master erstellt, eine Änderung in einem Script Agenten erstellt und im grafischen Benutzertool wollte ich mit die Änderungen ansehen die ich gemacht hatte.

Bei Agenten verfahren wir grundsätzlich so, daß der einzige scriptcode im Agenten der Aufruf einer init() methode in einer ScriptLib ist. Daher brauche ich mich um die Versionierung von Agenten nicht zu kümmern. Und den Code in ScriptLibs kann ich gut auch mit SVN / Tortoise vergleichen.

[flaite]

Wer Subversion hat, besitzt einen Grund nicht Git einzusetzen, weil er schon ein gutes System hat.
Wer kein Versionierungs-System hat, sollte sich aus meiner Sicht erstmal mit git auseinandersetzen, weil es ein sehr gutes System ist. Es setzt sich immer mehr durch und das hat klare Gründe. 

Für git gibts genauso ein Tortoise.

just for the record