Sourcecodeverwaltung mit Subversion

Hallo zusammen,

bin mir nicht ganz sicher, ob ich hier ganz richtig bin, falls nicht Beitrag bitte verschieben.
Also, wir setzen hier Subversion (Tortoise Client) als Sourcecodeverwaltung für unseren C-Code ein, und haben dies auch für LabView versucht.

Wir sind mehrer Personen die an verschiedenen LabView Projekten arbeiten. Alle LabView Projekten verwenden sehr viele gemeinsamme VIs (bsplw. eigene Hi-Level Gerätetreiber, eigene Protokollierung, eigene Konfigurationsverwaltung, ...).
Sobald jetzt irgendjemand eines der VIs nur abspeichert (ohne etwas zu verändern) wird dies ja als verändert markiert.
Macht nun jemand eine echte Änderung und commited diese, kann der andere dies nicht mehr updaten, da er selbst eine lokale Änderung hat.
Bisher habe ich durch den VI Vergleich vor dem commiten versucht herauszufinden ob es eine echte Änderung ist oder nur durch ein abspeichern verändert wurde. Wenn es keine echte Ändeurng war habe ich einen revert gemacht.

Dieses Verfahren ist meiner Meinung nach mehr als aufwändig (bin vom C Code eben was anderes gewöhnt), und der Vergleich ist auch sehr bescheiden.

Irgendwie habe ich die Vermutung, daß entweder wir hier etwas grundlegendes falsch machen, oder eine Verwaltung der VIs im Team mit Subversion nicht wirklich brauchbar ist.

Hat hier jemand Tips wie man dies am besten tun sollte, und was man zwingend unterlassen sollte?

Vielen Dank im Voraus.
MfG Stephan

Anzeige

Hallo Stephan,

wir nutzen zwar Git, haben aber oft das gleiche oder ein ähnlich gelagertes Problem. Gerade mit Hinblick auf die Quellcode-Verwaltung hat NI (mit LV 2010) eine Option eingefügt, die es erlaubt den Quellcode von kompilierten Code zu trennen und zu hinterlegen: http://zone.ni.com/reference/en-XX/help/...led_code/.
Da wir erst seit kurzem mit dieser Option arbeiten kann ich im Moment noch keine klare Aussagen darüber geben, habe aber irgendwie den Eindruck dass es die Häufigkeit des angesprochenen Problems doch reduziert hat.

Schöne Grüße
Falk

Hi
Folgendes Vorgehen sollte bei LabVIEW im Zusammenhang mit SCC (egal welches) eingehalten werden:
- VIs werden in Bibliotheken organisiert. Für eine Bibliothek gibt es einen verantwortlichen Entwickler. Nur dieser hat Commit-Rechte für das entsprechnde Verzeichnis.
- Es gibt einen Rechner (oder auch nur eine sparate Arbeitskopie) auf dem neue Releases von Applikationen bzw. Versionen von Bibliotheken erstellt werden. Hier steht auch die Master-Projektdatei.
- Jede Entwickler erzeugt sich sein eigenes Projekt.
- Bibliotheken von anderen Entwicklern werden nur ausgecheckt und aktualisiert, aber niemals commitet. Am besten aktualisiert man ein Bibliotheksverzeichnis auf eine bestimmte SCC-Revision, die einer bestimmten Version oder eienm bestimmten Release entspricht. Lokale Änderungen werden nur über den verantwortlichen Entwickler in das SCC-Repostory commitet.

Auf diese Weise lassen sich Konflikte leicht vermeiden und ein "Revert to Revision" von Bibliotheken anderer ist gefahrlos möglich. Auf diese Weise kann man auch relativ leicht eine Qualitätskontrolle einbauen, weil jeder verantwortliche Entwickler mit seinem Namen dafür steht.

Dieses Vorgehen funktioniert bei uns an der GSI ganz gut. Wir benutzen hier auch Subversion.

Seit einem Jahr übe ich auch mit Git. Das grundsätzlich Vorgehen bleibt gleich, aber Git erleichtert das Branching ganz ungemein. Die Disziplin des Master-, Release- oder Main-Development-Branch nicht zu verunstalten bleibt. Jeder Entwickler hat aber die Möglichkeit, die Sourcen von anderen zu überarbeiten und via Pull-Request samt Historie an den verantwortlichen Entwickler zu übermitteln, der dann die erwünschten Änderung in seinen eigenen Branch und danach in den Main-Development-Branch mergen kann.

Gruß Holger

Hallo zusammen,

vielen Dank erstmals.
@Falk
Wäre schön wenn Du über die weiteren Erkentnisse berichten könntest.

@Holger
Das hört sich schlüssig an, ist jedoch meiner Meinung nach viel zu kompliziert, und ich kann mir nicht vorstellen, daß dies bei uns umsetzbar ist (aber dies ist mein/ein anderes Problem).
Eine alternative die mir noch eingefallen ist, wäre das SVN so konfiguriert wird, daß man vor der VI Bearbeitung das VI locken muß. Somit wäre sichergestellt, daß immer nur einer ein VI bearbeitet.

Hat jemand Erfahrung (positive wie negative) mit dem automatischen mergen von VIs?

MfG Stephan

Wir sehen einfach zu, dass VI's die nur auf Grund von "mal eben reingeschaut" als geändert erkannt wurden, wieder innerhalb der Commit-Liste revertet werden. Ca. 1 mal die Woche gibt's trotzdem ein Konflikt - halb so wild: man redet kurz drüber und entscheidet sich gemeinsam für eine Version. Wir sind aber mit 7 Mann, bzw. 2-3 pro Projekt auch eine überschaubare Anzahl. (Wobei Standard-Lib VIs in der Tat nur in Absprache modifiziert werden dürfen.)

@dimitri84
So habe ich dies seither auch versucht/gehandhabt (die Betonung liegt auf ich, aber dies ist auch ein anderes Problem).
Wie habt ihr den Vergleich gemacht, auch mit der LabView IDE, oder gibt es da noch was anderes/einfacheres wo ich gleich mehrer VIs vergleichen kann und dann eine Aussage bekomme ob es nur kosmetische Änderungen sind?

MfG Stephan

(13.03.2013 09:38 )Stephan schrieb:  Wie habt ihr den Vergleich gemacht, auch mit der LabView IDE, oder gibt es da noch was anderes/einfacheres wo ich gleich mehrer VIs vergleichen kann und dann eine Aussage bekomme ob es nur kosmetische Änderungen sind?

In 99,9% der Fälle ist das reine Gedächnisleistung. Man weiß doch wo man dran gearbeitet hat ... Eine funktionierende Kommunikation ist bei uns völlig ausreichend. (Gestern tatsächlich das erste mal die compare-Funktion der IDE ausprobiert ... )