Frankensteinprojekt

q000te

Well-Known Member
Vorgeschichte:

Ich habe zur Zeit ein Projekt (mit harter Deadline Ende Februar), bei dem ein Fortran Simulationsmodul mit einer Visual Basic Oberfläche und diversen C Rechenmodulen gekoppelt ist. Ich soll das ganze etwas polieren.
Aktuell siehts echt grausam aus, kein SCM, keine Entwicklerdokumentation, unsortierte Quelldateien in diversen Ordnern wild verstreut.
Und natürlich hat jeder einen anderen Stand des Quelltextes, der ab und an von Hand zusammengeführt wird... :zitter:

Problem:

War schon immer so, wo kommen wir denn dahin, da muss ich ja zusätzlich etwas lernen bzw. mich einarbeiten(SCM).

Frage:

Wie bekomme ich alle Beteiligten dazu ein SCM wie hg oder git zu verwenden?
(Vom Server dafür mal abgesehen.)
 
Frage:

Wie bekomme ich alle Beteiligten dazu ein SCM wie hg oder git zu verwenden?
(Vom Server dafür mal abgesehen.)

Indem du es in git einpflegst und den beteiligten sagst, dass jetzt git verwendet wird.

Oder wie kann ich deine Frage verstehen?
 
Folgende Fragen sollten wohl gestellt werden:

- wieviele Entwickler arbeiten an dem Projekt
- mit welchen Tools (IDEs) arbeiten diese und sind damit vertraut (würden diese gewohnten Tools also wohl gerne beibehalten wollen
- welche SCMs werden von den eingesetzten IDEs unterstützt; können irgendwie direkt oder über Umwege eingebunden werden?
- Welche Betriebssysteme müssen unterstützt werden und welche Entwicklungsmodelle finden Anwendung; Muss/Soll alles zentral verwaltet werden (z.B. eher Subversion; oder macht ein DVCS mehr Sinn?)
- Welche Bestimmungen/Bedingungen müssen erfüllt werden (warum wurdest du gefragt das ganze zu polieren, und was sollst du erreichen?)
- Gestzliche Bestimmungen, die evtl. auch erfüllt werden müssen?

Daraus folgend sollte sich bestimmen lassen, welches SCM dafür am geeignetsten ist.

Einmal eingerichtet dürfen von dann ab neu generierte Softwareversionen nur noch aus Code generiert werden, welcher auch im SCM eingepflegt ist. Alles andere muss unterbunden werden.

Noch nicht genannte, mögliche Kandidaten (OSS): Subversion, Bazaar

Gerade bei unterschiedlichsten Entwicklern und auch Visual Basic mit im Spiel, weiß ich nicht ob "git" die beste Alternative wäre, da doch ziemlich Linux-zentrisch.

Neben einem SCM ist ein gemeinsam zugängliches Wiki (z.B. Dokuwiki) bestimmt auch hilfreich um die ganzen Informationen an einem zentralen Punkt zu sammeln, auf den jeder auch Zugriff drauf hat.

Das Ganze durchzusetzen (also deine Frage wie du die Beteiligten dazu bekommst das ganze auch zu nutzen) ist eher eine Management-Angelegenheit und muss von oben herab orchestriert werden. Du musst also den entsprechenden Plan ausarbeiten und so empfehlen das er dann auch als neue "Ordnung" allen Beteiligten "aufgezwungen" wird. Da niemand sich gerne etwas aufwingen lassen wird, hast du die besten Chancen wenn du im Vorfeld während der Ausarbeitung des Ganzen alle Beteiligen mit einbeziehst, so das alle den Eindruck haben auch aktiv an der Gestaltung mitgewirkt zu haben. Jemanden etwas aufzuzwingen von dem er von Anfang an dagegen ist, insbesonders wenn es für denjenigen eine Änderung/Aufgabe seiner Gewohntheiten bedeutet, währe wohl ein Scheitern abzusehen.
 
Und welche Punkte wären das?
Die genannten Punkte gehen überhaupt nicht auf zentrale oder verteilte Versionierung ein.
Und derzeit müssen die Angestellten erstmal die Vorteile sehen, die eine Versionierung mit sich bringt.
Darauf aufbauend können dann die Unterschiede abgewogen werden.
 
Einfach ansagen, dass wird jetzt so gemacht kann ich nicht. Bin sehr wahrscheinlich derjenige mit dem geringsten Gewicht im Projekt...

  • Anzahl der Entwickler: 5+5 (2 Standorte)
  • Zusätzlich wird in Heimarbeit gearbeitet
  • Visual Studio mit Intel Composer XE (Fortran)
  • Windows only, ob zentral oder dezentral ist eine gute Frage aktuell hat jeder quasi seinen eigenen Branch der irgendwann von Hand gemerget wird..
  • Es gibt einen ganzen batzen Bestimmungen, aber auf die muss ich zum Glück nicht eingehen, mein Part ist größenteils UI und interne Datenformate (grausige selbstgebastelte Lösungen mit den üblichen Problemen wie z.B. Größenbeschränkungen und so weiter)

Wegen Windows möchte ich eigentlich nicht git sondern eher hg oder subversion. Es gibt da http://visualhg.codeplex.com/ und http://www.visualsvn.com/.

Hmm, einfach wird das nicht. Erstmal vielen Dank!

Ich bin jetzt gespannt, was beim nächsten Treffen auf mich zukommt, wenn ich die Thematik anspreche...

Ein Update dazu gibt es also frühestens in 2 Wochen.
 
Je nach dem wie lange die Leute sich mit dem Mergen befassen, könnte man evtl mit dem Argument schon Freunde gewinnen. Mein Tipp wäre eine kleine Vorführung der Arbeitsschritte und zuletzt mal die Änderungen der letzten Zeit in wenigen Sekunden 'live' Mergen.

Ich habe leider die Erfahrung gemacht, das "neue" Tools und Arbeitsweisen nicht angenommen werden, wenn man nicht jemanden auf höherer Ebene überzeugen kann das die Einführung wirtschaftlich sinnvoll ist. Mag aber auch an meinem Alter liegen ... ;'(
 
Und welche Punkte wären das?
0 und 1 sind nicht zutreffend, 5 ist irreführend.
Die genannten Punkte gehen überhaupt nicht auf zentrale oder verteilte Versionierung ein.
Das ganze Dokument geht von zentraler Steuerung aus. Hier ist von Verwaltungsanbietern die Rede, ein Konzept das in DVCS nicht ins Schema passt.

  • Anzahl der Entwickler: 5+5 (2 Standorte)
  • Zusätzlich wird in Heimarbeit gearbeitet
  • Visual Studio mit Intel Composer XE (Fortran)
  • Windows only, ob zentral oder dezentral ist eine gute Frage aktuell hat jeder quasi seinen eigenen Branch der irgendwann von Hand gemerget wird..
  • Es gibt einen ganzen batzen Bestimmungen, aber auf die muss ich zum Glück nicht eingehen, mein Part ist größenteils UI und interne Datenformate (grausige selbstgebastelte Lösungen mit den üblichen Problemen wie z.B. Größenbeschränkungen und so weiter)
Klingt nach einem idealen Umfeld für DVCS. Jeder kann weiterhin auf seinem eigenen Repository rumfuhrwerkeln und Entwickler können munter changesets miteinander austauschen, ohne dass es zu einem großen Durcheinander kommt.

Die wichtigsten Vorteile sind natürlich das Protokoll, die Möglichkeit zwischen Versionen zu springen (will heißen unlimited undo/redo mit allen Verzweigungen) und das einfache mergen.
 
Doch, der erste Punkt besagt lediglich das die Verantwortung des Quellbaums transparent übertragen werden kann und durch Rechtemanagement weitere Einschränkungen möglich sind. Der nächste Punkt beschreibt Tags und Branches.
Dann kommt noch Versionsgeschichte, Kollaboration.
Der 5. Punkt passt wohl besser zu Jenkins als zu hg.
 
Meine Erfahrungen mit msysgit/TortoiseGit unter Windows, nicht mehr ganz frisch:
2 Repos hängen sich auf und lassen sich nicht updaten(Bitrig, NetBSD)
Bugs beim extrahieren einzelner Revisionen, stellenweise grausame UX mit TortoiseGit
Rattenschwanz von zus. Abhängigkeiten
 
Warum kein git unter Windows?

Hmm, ich habe eigentlich bislang noch keine guten Erfahrungen mit git unter Windows gemacht. Wobei git oder hg relativ egal ist, die nehmen sich nicht viel(vom Funktionsumfang).
Aber mit hg habe ich bislang noch keine neagtive Erfahrung unter Windows gemacht. :ugly:
Mit git konnte ich eine Zeit lang Bluescreens erzeugen, leider nicht sicher reproduzierbar so das ich keinen Bugreport verfasst habe...
Hg hingegen funktioniert einfach.

Von subversion will ich eigentlich nicht anfangen, es gibt noch ein paar Projekte die es verwenden und ich komme damit zurecht, aber so richtig warm bin ich damit nicht geworden.
Vorteil der verteilten SCM ist halt, dass es lokale und entfernte repos gibt/geben kann und wenn schwerwiegende Fehler auftreten, dann reißen sie nicht gleich alles in den Abgrund.
Wer von euch durfte schon mal einen abgerauchten subversion Server und die dortigen repos wiederherstellen? (Mir hat es gereicht, dass einmal mit anzusehen. Nicht gut!)

Der vollständigkeit halber, git Integration in Visual Studio:
 
Last edited:
Wer von euch durfte schon mal einen abgerauchten subversion Server und die dortigen repos wiederherstellen? (Mir hat es gereicht, dass einmal mit anzusehen. Nicht gut!)
Ja schon gemacht. Keine Probleme und unsere Repos sind über 600GB! :eek:
 
Ich hab mir letztens mal fossil angeschaut: http://fossil-scm.org
Das bringt direkt noch ein Wiki, nen Bugtracker usw. mit und das alles in einer einzigen Binary.
Für kleine Projekte ist das m.M.n. ideal.
 
Ich mag Fossil auch sehr (insbesonders für private, kleinere Projekte), muss allerdings dazu folgende Punkte anmerken:


- es speichert alles in einer einzigen SQLight Datenbank ab (was ein Vorteil wie auch ein Nachteil sein kann)
- die Unterstützung von IDEs zu Fossil lässt noch zu wünschen übrig (z.B. unterstützt Emacs von Hause aus git, bzr und afaik hg, aber noch kein Fossil)
- es ist nicht "idiotensicher"...man kann leicht durch erneutes Auschecken bestehende Veränderungen im Working-Tree wieder ungewollt zurücksetzen und damit verlieren. Bazaar handelt das z.B. wesentlich eleganter, in dem es automatisch Backup-Kopien der Dateien anlegt, im Falle einer Kollision. Bei Bazaar wird z.B. angestrebt das, egal was der User macht, es nicht unbeabsichtigt zum Datenverlust im Working-Tree kommen darf. In Fossil habe ich dieses Bestreben bisher leider vermisst.
- Offene Checkouts kann man nicht ohne weiteres bewegen (in anderen Pfad kopieren/bewegen). Ich habe dadurch schon mehrmals ein Fossil-Repository gehabt, welches sich nicht mehr ohne Umstände öffnen lassen wollte. Kann aber sein, das dies in der aktuellen Version mittlerweile besser gelöst ist. Generell empfiehlt es sich aber das Repository mit "close" zu schließen, dann zu bewegen, und dann wieder zu öffnen.
- Es ist nicht unbedingt für größere Projekte ausgelegt (laut Aussage einiger; nicht selbst verifiziert)
 
So eine SCM-Diskussion ist ja gut und schön, aber letztendlich haben da 100 Personen mindestens 150 Weltanschauungen. Das ist einfach Geschmackssache. Das Problem beim Frankensteinprojekt ist, dass es gar kein SCM gibt und man die Benutzer nun dazu bringen möchte, eines zu nutzen. Und dort ist es eigentlich egal welches, denn jedes SCM ist besser als gar keines. :)

Ich würde mich erst einmal informieren, ob es wirklich kein SCM gibt. Wenn die Hälfte der Entwickler lokal ein git nutzt, ist die Sache eigentlich schon geregelt. Auf den Vorschlag ein globales git einzuführen, würden 50% der Entwickler begeistert reagieren. Wenn mehrere SCM genutzt werden, würde ich serverseitig zu SVN raten. Denn SVN ist sozusagen das Englisch der SCM, praktisch jedes SCM kann gegen SVN als Backend arbeiten. Die Entwickler können weiternutzen, was sie gerade nutzen, das SCM ist eingeführt, alle weiteren Details kann man später klären. Wenn niemand ein SCM nutzt, ist erst einmal Überzeugungsarbeit nötig. Und da gilt "je einfacher, umso besser". git, hg und co mögen coole Tools sein, ihre Lernkurve ist aber gigantisch. Und wenn man erst einmal jemanden vom SCM überzeugen muss, sind Lernkurven der natürliche Feind.
 
Doch, der erste Punkt besagt lediglich das die Verantwortung des Quellbaums transparent übertragen werden kann und durch Rechtemanagement weitere Einschränkungen möglich sind.
Der Punkt an DVCS ist doch, dass es den Quellbaum überhaupt nicht gibt. Jeder hat ein vollwertiges Repository auf dem man uneingeschränkt arbeiten kann.
 
Soo, war eine schwere Geburt:

- offiziell gibt es gar nichts
- einer der Kollegen hat irgendwann vor ein paar Jahren für sich selbst auf seinem Rechner mit Subversion angefangen
- nach und nach hat sich das durchgesetzt bis letzendlich alle gegen den einen Subversionserver gearbeitet haben

Im lauf der nächsten Woche wird der auf eine eigene Maschine umgezogen und dann ist Subversion offiziell...

Also letzendlich ist hoffentlich nächste Woche alles gut. Subversion auf dem Server und ich kann dagegen mit Mercurial arbeiten :)

(Evtl. wäre es schneller gegangen, wenn ich mir eher die versteckten Ordner unter Windows angesehen hätte, dann wären die .svn sofort aufgefallen :D )
 
Back
Top