INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Sourcecodeverwaltung mit Subversion



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

12.03.2013, 07:54
Beitrag #1

Stephan Offline
LVF-Grünschnabel
*


Beiträge: 20
Registriert seit: Jun 2005

7 | 2011
2005
EN


Deutschland
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
12.03.2013, 08:30
Beitrag #2

Falk Offline
ja, das bin ich...
***


Beiträge: 343
Registriert seit: Jan 2006

8.0 :: 201x ::202x
2006
DE_EN


Deutschland
RE: Sourcecodeverwaltung mit Subversion
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

Currently: zzzZZZZZZZZ
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
12.03.2013, 09:53
Beitrag #3

BNT Offline
LVF-Freak
****


Beiträge: 740
Registriert seit: Aug 2008

5.0 - 22Q3
1999
EN

64291
Deutschland
RE: Sourcecodeverwaltung mit Subversion
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

NI Alliance Partner & LabVIEW Champion
GnuPG Key: 6C077E71, refer to http://www.gnupg.org for details.
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
13.03.2013, 07:18 (Dieser Beitrag wurde zuletzt bearbeitet: 13.03.2013 07:24 von Stephan.)
Beitrag #4

Stephan Offline
LVF-Grünschnabel
*


Beiträge: 20
Registriert seit: Jun 2005

7 | 2011
2005
EN


Deutschland
RE: Sourcecodeverwaltung mit Subversion
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
13.03.2013, 09:02
Beitrag #5

dimitri84 Offline
Astronaut
*****


Beiträge: 1.496
Registriert seit: Aug 2009

2020 Developer Suite
2009
DE_EN

53562
Deutschland
RE: Sourcecodeverwaltung mit Subversion
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.)

„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
13.03.2013, 09:38
Beitrag #6

Stephan Offline
LVF-Grünschnabel
*


Beiträge: 20
Registriert seit: Jun 2005

7 | 2011
2005
EN


Deutschland
RE: Sourcecodeverwaltung mit Subversion
@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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
13.03.2013, 10:04
Beitrag #7

dimitri84 Offline
Astronaut
*****


Beiträge: 1.496
Registriert seit: Aug 2009

2020 Developer Suite
2009
DE_EN

53562
Deutschland
RE: Sourcecodeverwaltung mit Subversion
(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 ... )

„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  LabVIEW SCC, PushOK, Tortoise und Subversion BNT 3 8.827 17.01.2013 14:19
Letzter Beitrag: BNT
  Verwaltung mehrere Projekte und gemeinsamer Bibliothek in Subversion Falk 1 5.695 15.01.2011 14:46
Letzter Beitrag: BNT
  Subversion revision in Exectuable Cardinal1664 3 4.479 15.06.2010 11:35
Letzter Beitrag: htw10870

Gehe zu: