Git Versionsmanagement für Domino Designer

[m3]

Nathan hat EGit für den Domino Designer portiert. Damit kann man Git zur Versionierung von Templates und Design-Elementen verwenden!

Don't get too excited. It's not some marvel of engineering. Mostly I just took the current EGit source code and commented out the DebugTrace calls that weren't added to the OSGi runtime until 3.5. It installs a few plugins that weren't part of the standard RCP until 3.5, mostly having to do with Java-based SSH calls. And it resolves a few constants that weren't in 3.4.

I really hope you try it out, especially with the Source Control Enablement plugin for DDE. The two parts together make it unbelievably easy to fork your templates and remerge them at any time.  No more running around with templates that have 15 backup copies of the same Form or individual developer staging areas for script libraries.

http://ntf.gbs.com/nathan/escape.nsf/d6plinks/NTFN-8FFSD4

[WernerMo]

Hallo Martin,

wo siehst Du den Vorteil gegenüber SVN (das mit 8.5.3 vollständig nutzebar sein soll)?

Gruß Werner

[m3]

SVN ist nur ein Zustand. (Siehe auch http://www.youtube.com/watch?v=4XpnKHJAok8 ). Git, ist - IMHO & soweit ich es bisher verstanden habe - viel eleganter, flexibler, mächtiger. Vor allem bei verteilten Teams, die auch mal offline sind, ...

[flaite]

Also ich arbeite nun seit 4 oder 5 Jahren mit svn.
In Teams mit Eincheckern von 1 bis ca. 40 lief das wirklich gut.
Git hat ein paar Vorteile für sehr, sehr große Teams und für offline-Fähigkeit.

Git funktioniert, aber die Worte "viel eleganter, flexibler, mächtiger" in Verbindung mit einem Version Control Systems hab ich das letzte mal in einem Projekt gehört, in dem uns IBM Synergy aufgezwungen wurde. Das war noch übler als Rational Clear Case und das ist wirklich nicht einfach, ein noch dysfunktionaleres Versional Control System zu erstellen als Rational ClearCase. Schliesslich wurds durch svn ersetzt.
Der normale Software-Arbeiter erwartet von einem Version Control System keine herausragende Flexibilität, sondern dass es nach gewissen nachvollziehbaren Regeln zuverlässig seine Arbeit tut und man im Falle von unausweichlich auftretenden Versionskonkflikten eine konfortable und zuverlässige Oberfläche zur Verfügung gestellt bekommt, um die Probleme selbstständig zu lösen.

Wer svn für Domino Entwicklung nutzen will, sollte sich in keinem Fall abschrecken lassen. Git ist nur eine Alternative eines gut funktionierenden Systems. Viel wichtiger ist es, sich in seinem Entwicklungsstil an Version Control Systeme zu gewöhnen. Es lohnt sich. Nach ein bischen Übung braucht man sich auch dann keine Sorgen machen, falls jemand mit einem Git-Bauchladen ankommt und svn durch git ersetzt wird. Für denjenigen, dessen source code in dem Source Control System liegt ist das nämlich sehr ähnlich.
Wichtigster Trick: OFT einchecken. Falls jemand anders denselben code bearbeitet wie man selber, hat der das Problem beide Versionen zu synchronisieren, wenn man selbst zuerst eincheckt. Egoistisch, aber sehr effektiv.  

[MadMetzger]

Wer svn für Domino Entwicklung nutzen will, sollte sich in keinem Fall abschrecken lassen. Git ist nur eine Alternative eines gut funktionierenden Systems. Viel wichtiger ist es, sich in seinem Entwicklungsstil an Version Control Systeme zu gewöhnen. Es lohnt sich. Nach ein bischen Übung braucht man sich auch dann keine Sorgen machen, falls jemand mit einem Git-Bauchladen ankommt und svn durch git ersetzt wird. Für denjenigen, dessen source code in dem Source Control System liegt ist das nämlich sehr ähnlich.

Ein paar kleine Feinheiten sind unterschiedlich auf Grund der unterschiedlichen Natur von SVN und GIT. Aber im Kern hast du recht, wichtig ist, dass man mit Version Control arbeitet und sich an gewisse Praktiken im Zusammenhang damit gewöhnt.

Wichtigster Trick: OFT einchecken. Falls jemand anders denselben code bearbeitet wie man selber, hat der das Problem beide Versionen zu synchronisieren, wenn man selbst zuerst eincheckt. Egoistisch, aber sehr effektiv.  

Das hat den netten Nebeneffekt, dass man mitunter sein Verhalten ändert und größere Änderungen in kleinere zerlegt, die dann in kleinen Schritten eingecheckt werden. Ich finde es neben häufigem Einchecken auch wichtig, dass man regelmäßig aktualisiert, um seine eigene Entwicklungsarbeit nicht von der Hauptrichtung abdriften zu lassen.

[flaite]

Das hat den netten Nebeneffekt, dass man mitunter sein Verhalten ändert und größere Änderungen in kleinere zerlegt, die dann in kleinen Schritten eingecheckt werden. Ich finde es neben häufigem Einchecken auch wichtig, dass man regelmäßig aktualisiert, um seine eigene Entwicklungsarbeit nicht von der Hauptrichtung abdriften zu lassen.

War augenzwinkernd gemeint. Natürlich gilt die Regel. Erst auschecken (update) und dann einchecken (commit).
Hab mal mit einem Noob zusammengearbeitet, der sich irgendwann beschwerte, dass er so oft mergen musste. Das lag einzig daran, dass er der seltsamen aber konsequent eingehaltenen Regel folgte, erst immer am Abend einzuchecken.
Ich mach in der Regel etwa alle 2 Stunden einen update/commit Zyklus.

[WernerMo]

hallo,

euch allen vielen Dank

Gruß Werner

[WernerMo]

Hallo,

nochmals vielen Dank an alle, bei heise gibts genau dazu seit heute auch einen schönen Artikel:

Die neue Freiheit bei der Versionskontrolle

Gruß Werner