Hi Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? Danke
H. R. schrieb: > Hi > Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? > > Danke Es ist nicht verboten, aber auch nicht üblich.
Altium Designer hat einen sehr brauchbaren svn-Support. fchk
VCS-Systeme verwalten Versionsstände üblicherweise als textueller diff zu ihrem Vorgänger. Wenn Du mit dem diff nichts mehr anfangen kannst (weil die grafische Software die fast identische Datei komplett neu - und irgendwie anders - schreibt), wird das zum Datengrab. Dann funktioniert kein merge mehr und Du kannst dir dein VCS an den Hut stecken. Mit einem PLM-System bist Du da besser bedient.
H. R. schrieb: > Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? Ein Hardwareentwickler dokumentiert seine Änderung auch und legt ebenfalls Versionsstände an auf die er ggf zurückgehen kann. Dazu sind aber die Tools der Softwerker weniger geeignet, weil sie auf der Verwaltung von Textdateien basieren. Stattdessen legt man für jeden Versionsstand ein Bävkupverzeichniss an und beschreibt Änderungen in einer Textdatei. Oder man kopiert/druckt die Zeichnung aus und markiert Änderungen in einer besonderen Farbe und archiviert diese (als Papier oder Scan). Man kann auch versuchen die Änderung computergestützt zu ermitteln, indem man am Computer nachstellt, wie man verschiedene Zeichnungsversionen quasi auf Transparentpapier übereinanderlegt sodas die Versionsunterschiede durchschimmern. Also Schematics/Layouts/etc. als verlustfreies Bitmap abspeichern (notfalls Screenshoot per "Druck-Taste") (bspw PNG) und dann mit gimp oder einer anderen Bildverarbeitung ein Differenzbild (Ebenen subtrahieren) erzeugt. PS: Wird heute die Traditionelle Versionsverwaltung mit Papier, Stift und Mappe nicht mehr gelehrt?! Oder sogar verboten?
H. R. schrieb: > Hi > Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? > > Danke Es stellen sich immer vier Fragen: Woher? Warum? Wohin? Wie? Woher: Es gibt genügend Möglichkeiten, vernünfitg saubere Versionskontrolle auch ohne SVN zu machen. S_oftware A_us P_olen kennt das ja auch nicht und trotzdem wird damit Beschaffung und Produktion damit gehandhabt. Warum: Wenn die übliche Prozesslandschaft diese Versionierung schlecht abbildet wird häufig schnell nach irgendeiner Versionskontrolle geschrien. DAs macht partiell Sinn aber nur solange die umgebenden prozesse damit mitspielen oder nachgezogen werden. Ist aber vom "Woher" abhängig. Wohin: Was will ich erreichen? Wenn as warum nicht geklärt ist ist auch schlecht das Wohin zu definieren da man den Ausgangspunkt und die Defizite schlecht kennt. Einfach die Dateien in ein SVN zu schieben hilft zwar zur Speicherung. Aber ich kann meinen HW-Entwicklungsstand bei einer Gruppe von 10 Entwicklern jeden Tag speichern, dann wird das schnell unübersichtlich. Oder jeden Meilenstein, dann kann das durchaus Sinn machen. Was mache ich dazwischen? Was passiert wenn ein Mann dazwischen ausfällt, ... Ist alles zwar abbildbar abedr zu walche Kosten. Und damit sind wir beim Wie: Es wurde schon angesprochen: Altium kann mit SVN oder Vaults (im Prinzip das gleiche) umgehen. Es verfügt aber auch über eine Historie jeder Änderung. Klar kannst Du einem SW-Entwickler dazu verdonnern jede Stunde oder jeden Tag Aus- und Einzuchecken. Wieviel Sinn das macht ist von der Umgebung abhängig. USW. Du siehst: Möglich? Ja. Sinnvoll? Hängt von Deinen Umständen ab. Bei uns wurde da schon mal drüber diskutiert. Wir machen KEIN SVN (Altium, Speicherung offline auf Server, Sicherung bei Meilensteinen). rgds rgds
Es spricht nichts dagegen, aber sehr viel dafür: die gesamte Historie ist an einem Ort, alte Stände können nicht verloren gehen oder manipuliert werden, es ist immer klar wer für welche Änderung verantwortlich ist, Backup von Projektdaten wird trivial. Das Argument, es gingen keine merges, lasse ich nicht gelten - manuell mergen kann man immer, und muss man auch bei Code oft genug. Und immerhin hat man einen exakt definierten Stand, was war in Branch 1 und was in Branch 2, und was danach, und kann im Zweifelsfall zurückverfolgen wann und warum eine Änderung gemacht wurde - auch wenn das ein bisschen Handarbeit erfordert. Dass hier „Backupverzeichnisse“ oder Papier vorgeschlagen wird lässt mir als zur Software konvertiertem E~Techniker die Haare zu Berge stehen, aber hat wohl den Grund, dass Hardwerker das Arbeiten mit diesen Tools einfach nicht gewöhnt sind.
Fpga K. schrieb: > H. R. schrieb: > >> Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? > > Ein Hardwareentwickler dokumentiert seine Änderung auch und legt > ebenfalls Versionsstände an auf die er ggf zurückgehen kann. Dazu sind > aber die Tools der Softwerker weniger geeignet, weil sie auf der > Verwaltung von Textdateien basieren. Jein. Diff und Merge funktionieren zwar nur mit Text bzw. zeigen nur für Text verwertbare Informationen. Aber praktisch alle VCS können auch mit Binärdateien umgehen. Und viele EDA Tools legen ihre Daten auch in einem Textformat (z.B. XML) ab. > Stattdessen legt man für jeden Versionsstand ein Bävkupverzeichniss an > und beschreibt Änderungen in einer Textdatei. Das hat keinerlei Vorteil gegenüber einem Commit in einem VCS. Im Gegenteil. Das VCS kümmert sich z.B. automatisch darum, Duplikate zu vermeiden. Es kann Commit-Mails verschicken. Es kann den Commit-Kommentar erzwingen und Plausibilitätsprüfungen vornehmen (z.B. einen DRC über das Layout laufen lassen). Nicht zuletzt kann man im VCS Hard- und Software-Teil zu den gleichen Zeitpunkten committen. Bei mir liegen immer beide Teile in einem gemeinsamen Projektverzeichnis und das gesamte Verzeichnis steht unter Versionskontrolle. > Oder man kopiert/druckt die Zeichnung aus und markiert Änderungen in > einer besonderen Farbe und archiviert diese (als Papier oder Scan). Das sollte hoffentlich ein Scherz sein.
Fpga K. schrieb: > Stattdessen legt man für jeden Versionsstand ein Bävkupverzeichniss an > und beschreibt Änderungen in einer Textdatei. Mit anderen Wort: Er pfuscht... Sorry aber diese hundertfachen Datei- und Verzeichniskopien zur "Versionierung" sind einfach nur murks. Dafür gibt es Tools. Wenn kein VCS dann eben ein PLM oder Dokumentenmanagementsystem.
Fpga K. schrieb: > H. R. schrieb: > >> Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? > > Ein Hardwareentwickler dokumentiert seine Änderung auch und legt > ebenfalls Versionsstände an auf die er ggf zurückgehen kann. Dazu sind > aber die Tools der Softwerker weniger geeignet, weil sie auf der > Verwaltung von Textdateien basieren. > > Stattdessen legt man für jeden Versionsstand ein Bävkupverzeichniss an > und beschreibt Änderungen in einer Textdatei. > Oder man kopiert/druckt die Zeichnung aus und markiert Änderungen in > einer besonderen Farbe und archiviert diese (als Papier oder Scan). > > Man kann auch versuchen die Änderung computergestützt zu ermitteln, > indem man am Computer nachstellt, wie man verschiedene > Zeichnungsversionen quasi auf Transparentpapier übereinanderlegt sodas > die Versionsunterschiede durchschimmern. Also Schematics/Layouts/etc. > als verlustfreies Bitmap abspeichern (notfalls Screenshoot per > "Druck-Taste") (bspw PNG) und dann mit gimp oder einer anderen > Bildverarbeitung ein Differenzbild (Ebenen subtrahieren) erzeugt. > > PS: > Wird heute die Traditionelle Versionsverwaltung mit Papier, Stift und > Mappe nicht mehr gelehrt?! Oder sogar verboten? Alternativ kann man auch seinen Feuerstein nehmen, ein Lagerfeuer anzünden und der Diff-Gottheit ein Tieropfer bringen. Es gibts schon einen Grund, warum man den Müll mit Stift, Papier und Mappe nicht mehr macht. Oder routest du auch noch mit Abziehbildchen und optischer Verkleinerung? SVN eignet sich ganz gut für PCB-Projekte. Einen Merge wirst du mit keinem Programm vernünftig hinbekommen. Mit dem Zähler hast du eine direkte Hausnummer über welchen Stand man redet, in den Kommentaren kannst du Veränderungen Dokumentieren, für die Produktion kannst du den Stand taggen. Eine Verzeichnisstruktur artet meistens aus: Ordner ->Projekt aktuell ->Projet neuer ->Projekt backup ->projekt backup backup ->projekt older u.s.w
:
Bearbeitet durch User
Bei uns wird alles versioniert, d.h. sowohl die entsprechenden Beschreibungsdateien für Software, Hardware, FPGA, usw. als auch Fotos, Protokolle und sonstige Dokumente. Durch die Kopplung von Subversion und Trac lassen sich dann auch die Verknüpfungen von Checkins mit Ticket realisieren. Trac-Tickets werden nicht nur für Fehler verwendet, sondern auch für anstehende Aufgaben und Verbesserungen. Es erfordert allerdings auch einen gewissen Planungsaufwand und die gewisse Weitsicht, wie die Repositories und daraus resultierenden Sandboxes aufzubauen sind. Dies betrifft vor allem auch die Mehrfachverwendung versionierter Elemente, z.B. Bibliotheken. Eines der wichtigsten Elemente bei der Verwendung von Versionskontrollsystemen sind aussagekräftige Checkin-Kommentare. Auch den Checkin-Vorgang als solchen sollte man wirklich ernstnehmen und sämtliche durchgeführte Arbeiten noch einmal kontrollieren. Die absolute Katastrophe sind Projektmitarbeiter, die völlig unreflektiert sämtlichen Scheiß in ihren Arbeitsverzeichnisse und darüber hinaus einchecken. Ein ganz wichtiges Thema ist auch die Versionierung von Artefakten wie z.B. Kompilaten und Logfiles. Natürlich ist es ungünstig, wenn nach jedem Compilerlauf tausende Dateien als geändert angezeigt werden, so dass die wirklich wichtigen Änderungen dabei in Vergessenheit geraten können. Daher hat es sich sehr bewährt, hier sparsam vorzugesehen. Allerdings müssen bei der Generierung offizieller Releases schon sämtliche generierten Dateien enthalten sein, damit man ggf. auch nach Jahren noch jeden Vorgang nachvollziehen kann. Ich hatte gerade erst gestern die Situation, dass ich in ein paar Builds von 2014 und 2015 hineinschauen musste, weil er Kunde ein paar Fragen zu alten Firmwareständen hatte. Solche Builds sollten aber vorzugsweise abseits der Arbeitsverzeichnisse versioniert bzw. archiviert werden. Und da hängt es auch gewaltig von den Konzepten des jeweiligen VCS ab. Subversion bildet Vorgänge wie das Vergeben von Tags oder Anlegen von Branches auf normale Kopiervorgänge ab. Das hat zwar den Nachteil, dass man einer Datei nicht sofort ansieht, wo sie sonst noch verwendet wird, aber dafür kann man eben sehr einfach außerhalb der normalen Verzeichnisse komplette Builds ablegen. Es hat sich durchaus bewährt, neben der von den Subversion-Autoren vorgeschlagenen Aufteilung in die Verzeichnisstrukturen trunk/tags/branches auch noch releases zu verwenden. Ein typischer Workflow sieht dann so aus, dass die Entwicklung auf trunk oder branches/<branchname> erfolgt und dann ein Versionsstand dann nach tags/<tagname> kopiert. Somit hat man dann einen Quellcodestand in Stein gemeißelt. Anschließend kopiert man solch ein Tag nach releases/<releasename> und führt dort die Erzeugung der Artekfakte durch, die selbstverständlich auch eingecheckt werden, d.h. inklusive Logfiles. Ggf. checkt man aber keine Einzeldateien ein, z.B. ein gezipptes Abbild der Sandbox. Auf diese Art und Weise kann man ggf. auch mehrere Builds eines Quellcodestandes durchführen, z.B. in unterschiedlichen Umgebungen.
Keiner N. schrieb: > SVN eignet sich ganz gut für PCB-Projekte. Einen Merge wirst du mit > keinem Programm vernünftig hinbekommen. Erstaunlicherweise funktioniert aber z.B. bei Altium Designer das Betrachten von Diffs ganz passabel. Besonders gut gelöst ist dabei, dass der Storage Manager die gespeicherten Zwischenstände und die per CVS/Subversion versionierten Stände in einer gemeinsamen Historie darstellt. Man kann sich dann beliebige Diffs zwischen lokaler und versionierter Historie anzeigen lassen. Seit AD 18 wird auch Git unterstützt, aber das habe ich noch nicht selbst ausprobiert.
H. R. schrieb: > Stellt ein HW Entwicklungsingenieur seine files unter git/svn/...? Das sind eher Tools für die SW-Entwicklung. Systeme zur Versionierung von Mechanik und Elektronik(-HW) laufen unter dem Begriff Computer-Integrated Manufacturing (CIM). Ein bekannter Hersteller wäre https://www.contact-software.com/de/ Da hast Du dann auch gleich eine Anbindung an SAP für Logistik und (Finanz-)Controlling.
Stellt der Hersteller der EDA-Software ein Diff- und ein Merge-Tool zur Verfügung, können Schaltpläne mit den meisten VCSen genauso komfortabel wie Textdateien verwaltet werden. Die Bereitstellung dieser Tools muss aber durch den EDA-Hersteller erfolgen, da ein VCS unmöglich jedes (evtl. sogar undokumentierte) Grafikformat unterstützen kann. Aber auch ohne diese Tools ist die Verwaltung von Schaltplänen sinnvoll, insbesondere dann, wenn das Hardwareprodukt auch Softwarekomponenten beionhaltet. Aber auch ohne diese Tools ist die Verwaltung von Schaltplänen mit einem "Software-VCS" durchaus sinnvoll, insbesondere dann, wenn das Produkt auch Softwarekomponenten (bspw. Firmware oder Treibersoftware für PCs) beinhaltet, weil mit jeder Hardwareänderung oft auch Softwareänderungen einhergehen. Wird beides mit demselben System verwaltet, sind die Änderungen automatisch miteinander synchronisiert.
Keiner N. schrieb: > Es gibts schon einen Grund, warum man den Müll mit Stift, Papier und > Mappe nicht mehr macht. Oder routest du auch noch mit Abziehbildchen und > optischer Verkleinerung? Wenn ich dem Servicetechniker/Handbestücker die Änderung als diff-Paket rüberschicke und nicht als Bebilderte Arbeitsanweisung, erschlägt der mich ;-)- das ist für mich ein guter Grund Unterschiede immer so zu dokumentieren, das der der diese kennen muss, was damit anfangen kann.
Andreas S. schrieb: > Bei uns wird alles versioniert, d.h. sowohl die entsprechenden > Beschreibungsdateien für Software, Hardware, FPGA, usw. als auch Fotos, > Protokolle und sonstige Dokumente. Durch die Kopplung von Subversion und > Trac lassen sich dann auch die Verknüpfungen von Checkins mit Ticket > realisieren. Trac-Tickets werden nicht nur für Fehler verwendet, sondern > auch für anstehende Aufgaben und Verbesserungen. ACK > Es erfordert allerdings auch einen gewissen Planungsaufwand und die > gewisse Weitsicht, wie die Repositories und daraus resultierenden > Sandboxes aufzubauen sind. Dies betrifft vor allem auch die > Mehrfachverwendung versionierter Elemente, z.B. Bibliotheken. ACK > Eines der wichtigsten Elemente bei der Verwendung von > Versionskontrollsystemen sind aussagekräftige Checkin-Kommentare. Auch > den Checkin-Vorgang als solchen sollte man wirklich ernstnehmen und > sämtliche durchgeführte Arbeiten noch einmal kontrollieren. Die absolute > Katastrophe sind Projektmitarbeiter, die völlig unreflektiert sämtlichen > Scheiß in ihren Arbeitsverzeichnisse und darüber hinaus einchecken. ACK > Ein ganz wichtiges Thema ist auch die Versionierung von Artefakten wie > z.B. Kompilaten und Logfiles. Natürlich ist es ungünstig, wenn nach > jedem Compilerlauf tausende Dateien als geändert angezeigt werden, so > dass die wirklich wichtigen Änderungen dabei in Vergessenheit geraten > können. Daher hat es sich sehr bewährt, hier sparsam vorzugesehen. > Allerdings müssen bei der Generierung offizieller Releases schon > sämtliche generierten Dateien enthalten sein, damit man ggf. auch nach > Jahren noch jeden Vorgang nachvollziehen kann. Ich hatte gerade erst > gestern die Situation, dass ich in ein paar Builds von 2014 und 2015 > hineinschauen musste, weil er Kunde ein paar Fragen zu alten > Firmwareständen hatte. Solche Builds sollten aber vorzugsweise abseits > der Arbeitsverzeichnisse versioniert bzw. archiviert werden. Und da > hängt es auch gewaltig von den Konzepten des jeweiligen VCS ab. > Subversion bildet Vorgänge wie das Vergeben von Tags oder Anlegen von > Branches auf normale Kopiervorgänge ab. Das hat zwar den Nachteil, dass > man einer Datei nicht sofort ansieht, wo sie sonst noch verwendet wird, > aber dafür kann man eben sehr einfach außerhalb der normalen > Verzeichnisse komplette Builds ablegen. Es hat sich durchaus bewährt, > neben der von den Subversion-Autoren vorgeschlagenen Aufteilung in die > Verzeichnisstrukturen trunk/tags/branches auch noch releases zu > verwenden. Ein typischer Workflow sieht dann so aus, dass die > Entwicklung auf trunk oder branches/<branchname> erfolgt und dann ein > Versionsstand dann nach tags/<tagname> kopiert. Somit hat man dann einen > Quellcodestand in Stein gemeißelt. Anschließend kopiert man solch ein > Tag nach releases/<releasename> und führt dort die Erzeugung der > Artekfakte durch, die selbstverständlich auch eingecheckt werden, d.h. > inklusive Logfiles. Ggf. checkt man aber keine Einzeldateien ein, z.B. > ein gezipptes Abbild der Sandbox. Auf diese Art und Weise kann man ggf. > auch mehrere Builds eines Quellcodestandes durchführen, z.B. in > unterschiedlichen Umgebungen. Von ganzem Herzen & Hirn ein 100% FULL ACK Darum auch eine vollständige Zitierung und obendrauf extra den Hinweis dass dies auch f. HW, Produktionsunterlagen, Anleitungen, Manuale, Architektur- & Designdokumente, Vorträge, Schulungen etc. pp. sinnvoll und praktikabel ist.
bitwurschtler schrieb: > Keiner N. schrieb: >> Es gibts schon einen Grund, warum man den Müll mit Stift, Papier und >> Mappe nicht mehr macht. Oder routest du auch noch mit Abziehbildchen und >> optischer Verkleinerung? > > Wenn ich dem Servicetechniker/Handbestücker die Änderung als diff-Paket > rüberschicke und nicht als Bebilderte Arbeitsanweisung, erschlägt der > mich ;-)- das ist für mich ein guter Grund Unterschiede immer so zu > dokumentieren, das der der diese kennen muss, was damit anfangen kann. Was für ein dümmliches Nicht-Argument. Ich darf meinen Workflow nicht omptimieren, weil irgendwo am Ende der Kette jemand sitzen könnte, der noch in der Steinzeit lebt? Entweder sucht man sich jemand, der schon auf elektronische Datenverarbeitung <hüstel> umgestellt hat. Oder man konvertiert seine Daten (den Laser im Drucker "hochskillen", damit er auf Steintafeln brennen kann?) Die Entscheidung ist am Ende eine betriebswirtschaftliche.
Axel S. schrieb: > bitwurschtler schrieb: >> Keiner N. schrieb: >>> Es gibts schon einen Grund, warum man den Müll mit Stift, Papier und >>> Mappe nicht mehr macht. Oder routest du auch noch mit Abziehbildchen und >>> optischer Verkleinerung? >> >> Wenn ich dem Servicetechniker/Handbestücker die Änderung als diff-Paket >> rüberschicke und nicht als Bebilderte Arbeitsanweisung, erschlägt der >> mich ;-)- das ist für mich ein guter Grund Unterschiede immer so zu >> dokumentieren, das der der diese kennen muss, was damit anfangen kann. > > Was für ein dümmliches Nicht-Argument. Häh? Form follows function ist "dümmlich"? Erklär mal! Vielleicht wirds an einem andere beispiel verständlicher: Firmware auf Gerät mit Hardwarestand A funktioniert, selber Software auf Hardwarestand B nicht. Jetzt wird der Hardwerker nach den den Unterschieden zwischen A und B gefragt. Mit welcher Antwort sind die Fragestellender eher zufrieden: a) Diff-Auszug aus CVS/svn der Speicherstände b) Ausdruck/PDF von Schaltplan mit Markierung c) textuelle Beschreibung der Unterschiede Es heisst ja nicht das CVS/SVN komplett untauglich ist, man kann damit schon Datensätze zeitstempel basiert erhalten und rekonstruieren. Aber zur Dokumentation von Änderungen ist es in der Hardwareentwicklung oft unzureichend, da bedient man sich doch der klassischen tools. Nicht jedes Problem wird durch Computereinsatz kleiner, manchmal entsteht es erst durch eine Sklavische Fixierung auf Softwaretools. Auch in der Softwareentwicklung ist IMHO eine Änderung besser in Worten beschrieben (Optimierung auf Systeme mit weniger Speicher) als mit (nackten) Diff-Auszug.
Es gibt ggf.(!) einen/mehrere aktuelle Arbeitsstände. Jede individuell an einen Kunden/Öffentlichkeit gebrachte Version wird versioniert/archiviert und nur bei Bugs oder Änderungswünschen angefasst. Und dann wird auch nur diese archivierte Version bearbeitet und unter einer neuen Versionsnummer archiviert nach Herausgabe. Damit sind alle herausgegebenen Versionen (inkl. Dokumentation, Manual etc.) archiviert. Wird eine neue Version erstellt, passiert dies unter einem neuen Arbeitstitel mit anschließender Archivierung. SVN und ähnliches lohnt sich mMn erst bei großen Teams, was sich bei verschiedenen Arbeitsgebern gezeigt hat. Hierunter fallen 20 Mann Klitschen definiv nicht, sondern eher ab 200 Personen aufwärts, wo dann in der Entwicklung für eine Produktgruppe z.B. bis 50 Personen herangezogen werden könnten.
bitwurschtler schrieb: > a) Diff-Auszug aus CVS/svn der Speicherstände Ja, indem man je nach Dokument diese Diffs tatsächlich in Textform (z.B. Stücklisten, Bestückungsdaten, Signallisten o.ä.) oder grafisch weiterverarbeitet, z.B. mittels Gerber Viewer Layoutunterschiede darstellt. > b) Ausdruck/PDF von Schaltplan mit Markierung Es wäre eine Katastrophe, nur Schaltpläne mit händischen Markierungen weiterzuverwenden. Wichtig ist doch, dass auch die Änderungen in dem betreffenden EDA-System vorgenommen *und als solche kenntlichgemacht werden*. Natürlich kritzele auch in während der Hardwareinbetriebnahme auf ausgedruckten Schaltplänen herum, ebenso auch andere Akteure. Solch ein wichtiges Dokument wird anschließend natürlich gescannt (oder behelfsweise mit der Digitalkamera fotografiert) und ins Versionskontrollsystem eingecheckt. > c) textuelle Beschreibung der Unterschiede Diese textuellen Beschreibungen gehören in den Checkin-Kommentar. Natürlich kann und soll man auch separate Textdokumente versionieren. Ein weiterer, sich als äußerst praktikabel erweisender Weg besteht darin, solche Beschreibungen in einem Wiki zu pflegen. Wenn das Wiki mit dem Versionskontrollsystem gekoppelt ist (z.B. Trac mit Subversion, JIRA/Confluence mit div. VCS), sieht man auch gleich den Zusammenhang zwischen Originalstand, nachträglichen Änderungen, zugehörigen Tickets und Checkins. > Es heisst ja nicht das CVS/SVN komplett untauglich ist, man kann damit > schon Datensätze zeitstempel basiert erhalten und rekonstruieren. So etwas sollte man aber nur im Sinne einer Lamport-Uhr betrachten. > Aber > zur Dokumentation von Änderungen ist es in der Hardwareentwicklung oft > unzureichend, da bedient man sich doch der klassischen tools. Was nützt es, irgendwelche Änderungen nur in Papierform zu notieren, wenn sie z.B. auch für künftige Layoutversionen benötigt werden? Ach ja, man kann versuchen, sich wichtig oder unersetzbar zu machen, indem man solche Änderungslisten nur in seinem eigenen Schrank hortet, so dass Dritte nicht erfahren, was geändert wurde. Wenn ich so etwas bemerke, werde ich etwas ungehalten. > Nicht > jedes Problem wird durch Computereinsatz kleiner, manchmal entsteht es > erst durch eine Sklavische Fixierung auf Softwaretools. Das stimmt durchaus. Auf den konkreten Fall angewandt ist es jedoch Unsinn. Handschriftliche Notizen sind wichtig für kurzfristige Zwecke, aber nicht für die langfristige Pflege eines Projektes. > Auch in der Softwareentwicklung ist IMHO eine Änderung besser in Worten > beschrieben Klar, der Compiler kann natürlich unglaublich viel mit einem ausgedruckten Quellcode anfangen, auf dem handschriftliche Notizen angebracht sind... > (Optimierung auf Systeme mit weniger Speicher) als mit > (nackten) Diff-Auszug. Speicherplatz ist auf Entwicklungsrechnern heutzutage überhaupt kein Problem mehr. Da geht es vielmehr um Nachverfolgbarkeit von Änderungen.
A. schrieb: > SVN und ähnliches lohnt sich mMn erst bei großen Teams, was sich bei > verschiedenen Arbeitsgebern gezeigt hat. Hierunter fallen 20 Mann > Klitschen definiv nicht, sondern eher ab 200 Personen aufwärts, wo dann > in der Entwicklung für eine Produktgruppe z.B. bis 50 Personen > herangezogen werden könnten. Völliger Unsinn. Gerade SVN ist sogar für Einzelkämpfer sehr gut einsetzbar, da es einen vernachlässigbaren Administrationsaufwand bedeutet.
A. schrieb: > SVN und ähnliches lohnt sich mMn erst bei großen Teams, was sich bei > verschiedenen Arbeitsgebern gezeigt hat. Hierunter fallen 20 Mann > Klitschen definiv nicht, sondern eher ab 200 Personen aufwärts, wo dann > in der Entwicklung für eine Produktgruppe z.B. bis 50 Personen > herangezogen werden könnten. Huh? CM (Configuration Management) lohnt ab einer Person. Sogar im Privat-/Bastel-Bereich ;-)
Einfach eine aufsteigende Zahl hinter den Dateinamen packen, mit jeder Änderung/Version wird um 1 hochgezählt und dann abspeichern. Schon klappt es mit der Versionsverwaltung, es ist digital abgespeichert und man kann trotz allem noch alles nachvollziehen.
A. schrieb: > Es gibt ggf.(!) einen/mehrere aktuelle Arbeitsstände. Jede individuell > an einen Kunden/Öffentlichkeit gebrachte Version wird > versioniert/archiviert und nur bei Bugs oder Änderungswünschen > angefasst. Und dann wird auch nur diese archivierte Version bearbeitet > und unter einer neuen Versionsnummer archiviert nach Herausgabe. Es ist (leider) nicht immer so einfach, hängt auch vom Umfeld ab. Compliance-Anforderungen steigen überall, QS-Anforderungen sind in bestimmten Bereichen (zB Luftfahrt) extrem. Neben dem "normalen" Änderungswahnsinn ;-) gibt es noch so nette Sachen wie RfD, Waiver, CIDLs, ABCLs, Quality Gates, ... die der Kunde in einen gesicherten Prozess eingebunden sehen will (welcher auch auditiert wird). Eine Tool-Unterstützung durch ein SCM (Subversion, cvs, ...) ist hier fast verpflichtend, genauso wichtig sind aber die darüber liegenden (oder begleitenden) Prozesse (und hier geraten auch die "großen" PDM/PLM-Systeme schon mal an ihre Grenzen). Aber das alles funktioniert nur, wenn man schon "im Kleinen" beginnt, sich mit einem Tool wie Subversion oder Git zu beschäftigen. Auch und vor allem im HW-Bereich (und noch viel mehr wenn es die HW/SW-Kombi ist)
Angehängte Dateien:
Für mich ist das formalistischer Overhead. Genauso wie iso9001 nur Formalismus ist.
Ich würde es machen, es spricht nichts dagegen aber vieles dafür: Vorteile: * Es entsteht ein aussagekräftiges Changelog, ganz automatisch nebenbei. * Alte Versionen gehen nicht mehr versehentlich verloren, selbst der größte Schusselkopf wird es nicht mehr schaffen irgendeinen alten Zwischenstand oder den Prototypen von letzter Woche von dem man heute gerne mal den Schaltplan bräuchte versehentlich zu überschreiben, umzubenennen, zu verwechseln oder dergleichen. Nachteile: * keine
:
Bearbeitet durch User
Ein HW Entwickler macht seine Sachen fertig. Und fertig ist es wenn es funktioniert und alle Anforderungen erfuellt sind. Da braucht es keine Versionskontrolle oder sonstiges Management. Ist alles Kindergarten und Beschaeftigungstherapie. :-)
Mark W. schrieb: > Ein HW Entwickler macht seine Sachen fertig. Und fertig ist es wenn es > funktioniert und alle Anforderungen erfuellt sind. Klar. Deshalb ist der erste Prototyp auch gleich das serienreife Design. Alles gelingt immer gleich beim ersten Wurf.
Andreas S. schrieb: > bitwurschtler schrieb: >> a) Diff-Auszug aus CVS/svn der Speicherstände > > Ja, indem man je nach Dokument diese Diffs tatsächlich in Textform (z.B. > Stücklisten, Bestückungsdaten, Signallisten o.ä.) oder grafisch > weiterverarbeitet, z.B. mittels Gerber Viewer Layoutunterschiede > darstellt. Bis zur Erstellung der Gerberdateien ist es ein langer Weg, manchmal Wochen... >> b) Ausdruck/PDF von Schaltplan mit Markierung > > Es wäre eine Katastrophe, nur Schaltpläne mit händischen Markierungen > weiterzuverwenden. Wichtig ist doch, dass auch die Änderungen in dem > betreffenden EDA-System vorgenommen *und als solche kenntlichgemacht > werden*. Ich kenn kein Schaltplanprogramm bei dem das möglich ist, vielleicht sollte ich mich mal von einen Firmenverteter besuchen lassen. Und ich spreche auch nicht von der ausschliesslischen Verwendung von händischen Markierungen. Ein BackUp vom Datensatz gehört selbstredent dazu. Klar kann man CVS/svn auch als BackUp-System verwenden. Aber das ist nur ein Aspekt der Versionsverwaltung. > Natürlich kritzele auch in während der Hardwareinbetriebnahme auf > ausgedruckten Schaltplänen herum, ebenso auch andere Akteure. Solch ein > wichtiges Dokument wird anschließend natürlich gescannt (oder > behelfsweise mit der Digitalkamera fotografiert) und ins > Versionskontrollsystem eingecheckt. Jup, da unterscheidet uns nix. >> c) textuelle Beschreibung der Unterschiede > > Diese textuellen Beschreibungen gehören in den Checkin-Kommentar. > Natürlich kann und soll man auch separate Textdokumente versionieren. HM, Checkin-Kommentare haben den Nachteil das man das CVS-frontend braucht um sie lesen zu können. Und oft sind's halt Referenzen auf andere Dokumente die ein Aussenstehender nicht kennt. Beispiel "Bugfix für BugReport A123 (Screen-Freeze bei unvollständigen umount" Da lob ich mir eine Änderungbeschreibung die mit den Worten des Anwenders geschrieben ist. > Ein weiterer, sich als äußerst praktikabel erweisender Weg besteht > darin, solche Beschreibungen in einem Wiki zu pflegen. Wenn das Wiki mit > dem Versionskontrollsystem gekoppelt ist (z.B. Trac mit Subversion, > JIRA/Confluence mit div. VCS), sieht man auch gleich den Zusammenhang > zwischen Originalstand, nachträglichen Änderungen, zugehörigen Tickets > und Checkins. Wiki hab ich nich auf dem Schirm, guter Tipp. Nachteil ist wieder das man Computer/Netzwerkzugang braucht um es zu lesen. >> Es heisst ja nicht das CVS/SVN komplett untauglich ist, man kann damit >> schon Datensätze zeitstempel basiert erhalten und rekonstruieren. > > So etwas sollte man aber nur im Sinne einer Lamport-Uhr betrachten. ?Kenn ich nicht! > >> Aber >> zur Dokumentation von Änderungen ist es in der Hardwareentwicklung oft >> unzureichend, da bedient man sich doch der klassischen tools. > > Was nützt es, irgendwelche Änderungen nur in Papierform zu notieren, > wenn sie z.B. auch für künftige Layoutversionen benötigt werden? Ach ja, > man kann versuchen, sich wichtig oder unersetzbar zu machen, indem man > solche Änderungslisten nur in seinem eigenen Schrank hortet, so dass > Dritte nicht erfahren, was geändert wurde. Wenn ich so etwas bemerke, > werde ich etwas ungehalten. Klare Ansage: Ich spreche hier nicht von Papier als einzige Datenhaltung. Auch nicht von Schrank, solche Dokumente gehören gescannt ins Dokumentationsverzeichniss. Alle Konstruktionsdaten müssen auch bei Abwesentheit verfügbar sein. Ungehalten werde ich wenn ein Konstrukteur erst stundenlang Datensätze aus der Revisions/Konfigurationsverwaltung holen und mit der passende Software in ein verständliche Dokuement konvertieren muss um die Hauptunterschiede benennen zu können. Oder diesen Vorgang bei der nächsten Nachfrage Wochenspäter wiederholen muss. In der Softwarentwicklung geht das noch - aus einem diff lesen zu können was geändert wurde. Bei Schaltplänen ist es mir noch nicht gelungen aus einem CVS-diff zu erkennen das beispielsweise nur die Steckerplatzierung leicht verändert wurde. >> Nicht >> jedes Problem wird durch Computereinsatz kleiner, manchmal entsteht es >> erst durch eine Sklavische Fixierung auf Softwaretools. > > Das stimmt durchaus. Auf den konkreten Fall angewandt ist es jedoch > Unsinn. Handschriftliche Notizen sind wichtig für kurzfristige Zwecke, > aber nicht für die langfristige Pflege eines Projektes. Doch auch langfristig muss man die Unterschiede zwischen den Hardwarerevisionen benennen können. Da macht man es sich mit persönlichen Notizen die natürlich auch gescannt abgelegt sind, leichter. >> Auch in der Softwareentwicklung ist IMHO eine Änderung besser in Worten >> beschrieben > > Klar, der Compiler kann natürlich unglaublich viel mit einem > ausgedruckten Quellcode anfangen, auf dem handschriftliche Notizen > angebracht sind... Ich meine ja Hardware-Sourcen aka Schematic; die bekommt ja üblicherweise kein Compiler vorgeworfen. Das ist ja der grosse Unterschied zwischen Software- und Hardwareänderungsbeschreibung. Die Hardwareänderung macht ein Mensch oder die Maschine die von einem Menschen eingerichtet wird. Der muss die Änderungsbeschreibung verstehen, deshalb sollte es diese auch menschenlesbar geben. >> (Optimierung auf Systeme mit weniger Speicher) als mit >> (nackten) Diff-Auszug. > > Speicherplatz ist auf Entwicklungsrechnern heutzutage überhaupt kein > Problem mehr. Da geht es vielmehr um Nachverfolgbarkeit von Änderungen. Du hast mich falsch verstanden, ich meinte das als Beispiel für die textuellen Änderungsbeschreibung eine Softwareänderung.
Na ja fertig ist man erst wenn man es Serienreif hat... ABER dann hat man da noch eine Produktverbesserung da noch eine Änderung etc. Es geht ja um die Versionskontrolle auf dem weg der entsprechenden Iterationsschritte... Und kosten darf es auch alles nix. Wenn man bedenkt das Pulsonix mit Vault so etwas bereits unterstützt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.