Moin Leute Ich habe ja für Versionskontrolle für Hardware bisher eher SVN den Vorzug gegeben, weil ich das das Herumgebranche für Hardware nicht als sinnvoll erachtet habe. Diese Meinung ändere ich gerade: Ich bürste gerade ein Eagleprojekt auf Altium um, inkl. einiger Änderungen, Anlegen zahlreicher Bauteile und Zeitdruck, da daß Teil sehr bald nochmal gefertigt werden soll, da sind Verzweigungen sehr nützlich. Jedenfalls habe ich gerade das hier gefunden und wollte es mal herumreichen. Vielleicht findet es der ein oder andere nützlich: https://content.allspice.io/en-us/git-for-hardware-guide
Wühlhase schrieb: > Moin Leute > > Ich habe ja für Versionskontrolle für Hardware bisher eher SVN den > Vorzug gegeben, weil ich das das Herumgebranche für Hardware nicht als > sinnvoll erachtet habe. Na ja, sinnvoll ist es schon, ist eher ne Frage, was ein git-diff für bestimmte Dateien leisten soll bzw. obs da was gescheites gibt. Binärdateien an sich sind durch git-lfs weniger problematisch geworden - die Datenmenge, die archiviert wird ist auch beim SVN gigantisch, da sieht mans nur weniger. > Diese Meinung ändere ich gerade: Ich bürste gerade ein Eagleprojekt auf > Altium um, inkl. einiger Änderungen, Anlegen zahlreicher Bauteile und > Zeitdruck, da daß Teil sehr bald nochmal gefertigt werden soll, da sind > Verzweigungen sehr nützlich. Grundsätzlich keine schlechte Sache, glaub ich. Git oder Svn - beides gewöhnungsbedürftig, gerade bzgl. Externals/Submodulen. Aber dezentralere Versionierung hat auch was für sich.
Wühlhase schrieb: > Jedenfalls habe ich gerade das hier gefunden und wollte es mal > herumreichen. Vielleicht findet es der ein oder andere nützlich: > https://content.allspice.io/en-us/git-for-hardware-guide Ich werde mich nicht sicher nicht registrieren um dieses 80S-Pamphlet downzuloaden und zu lesen. Falls Du das kennst, kannst Du ja hier ne Liste von Vorteilen von Git gegenüber SVN hervorheben im Konkreten Anwendungsfall aufpsalmodieren. Git für ja gerne als vorteilhaft für Teams angepriesen, während bei PCB die Fertigungsverantwortlichkeit bei genau einer Person liegen sollte. Nicht das irgendein Teilschaltplanschnösel quasi von hinten noch den Datensatz variiert. Bei Software kann man solche inkompatiblen Zuarbeitn mit continous testing and delivering quasi über Nacht ausbügeln. Bei PCB's merkt solchen unabgestimmten Scheiss erst bei der PCB-Inbetriebnahme 4 Wochen später. Und auch SVN bietet Branches oder labels um ein bouquet an files in verschiedenen Versionsständen zu beherrschen.
Master of Disaster schrieb: > Ich werde mich nicht sicher nicht registrieren Was hindert dich daran, als Namen Bart Simpson anzugeben?
Master of Disaster schrieb: > während bei PCB > die Fertigungsverantwortlichkeit bei genau einer Person liegen sollte. Genau das macht ja eine Versionskontrolle. Du kannst Änderungen einchecken, das bedeutet aber noch lange nicht das Sie in den main branch übernommen werden. Bei Software läuft das nicht anders. Wird einfach selten unterstützt und ist ungewohnt. Seitdem eagle xml hat mache ich Versionskontrolle. Das ist wirklich super, allein die Versionshistorie ist viel wert. Leider gibt es kein diff um Änderungen zu sehen. Wenn ich das brauche hab ich n batch der mit imagemagick beide Versionen abwechselnd angezeigt (gif) oder farblich markiert (pdf). Da ein Design bei eagle idR. aus Schaltplan und Brd besteht (sog. F/B annotation) verliert man auch nicht den überblick.
Für einen Hardwörker ist es von Vorteil, wenn man Google als Suchmaschine benutzen kann;-)
Mucky F. schrieb: > Master of Disaster schrieb: >> während bei PCB >> die Fertigungsverantwortlichkeit bei genau einer Person liegen sollte. > > Genau das macht ja eine Versionskontrolle. ASber der Fertiger/Bestücker kann mit dem git/svn nicht reden wie mit einem menschen. Wenn ich dem sage, hol dir die BOM für die bestellung aus dem Main-Branche, lässt der sich die trotzdem per Email schicken und fragt persönlich nach delta's (unterschiede zur bestellung davor) und irgendwelchen anderen Files (bspw. PickundPlace) andstatt diese aus dem SVN-Hauptzweig zu nehmen. Von Ihm erzeugte Files (ERC-Berichte etc.) lässt der Fertiger auch lieber vom Ansprechpartner selbst einchecken, als der er sich die Müße macht, den passenden branch etc zu finden.
GIT, das war doch der Schrotthaufen für Software, in der Bastler ihren halbfertigen nicht-funktionierenden code abkippen in der Hoffnung dass andere ihn aufräumen und reparieren, weil sie selbst dazu keine Lust haben und ihre Fähigkeiten übersteigt. So wie /dev/null für deren Software besser wäre, so tut es der lokale Elektroschrotthof für Hardware.
Bist du mit W.S. verwandt? Git ist ein Programm zur Versionsverwaltung, darin kann man nichts abkippen.
Hardwareentwickler kapieren sowas wie SVN oder GIT nicht. Alles was da über freigegebene Laufwerke raus geht ist für die böse SW-Magie. Vergebliche Liebesmüh, die da irgendwie raufheben zu wollen. Dreht man halt drei bis vier Runden mehr bei jedem Projekt, weil irgendein externer Entwickler das falsche Bauteil geändert hat. Völlig unbemerkt. Oder weil wieder mal der falsche Stand an den Fertiger rausgegeben wurde nach dem man das Projekt zig mal kopiert hat. Die Namen sehen dann im Laufwerk so aus: - Project_XYZ_draft - Project_XYZ_working - Project_XYZ_do_not_use - Project_XYZ_redesign_new - Project_XYZ_version2 - Project_XYZ_internal_only - Project_XYZ_eeprom_changed - Project_XYZ_newCPU - Project_XYZ_test Ein Saustall. Steht die SW schon besser da, weil der Verzug bei der HW liegt.
:
Bearbeitet durch User
Master of disaster schrieb: > ASber der Fertiger/Bestücker kann mit dem git/svn nicht reden wie mit > einem menschen. > Wenn ich dem sage, hol dir die BOM für die bestellung aus dem > Main-Branche, lässt der sich die trotzdem per Email schicken und fragt > persönlich nach delta's (unterschiede zur bestellung davor) und > irgendwelchen anderen Files (bspw. PickundPlace) andstatt diese aus dem > SVN-Hauptzweig zu nehmen. Von Ihm erzeugte Files (ERC-Berichte etc.) > lässt der Fertiger auch lieber vom Ansprechpartner selbst einchecken, > als der er sich die Müße macht, den passenden branch etc zu finden. Und?
Cyblord -. schrieb: > Hardwareentwickler kapieren sowas wie SVN oder GIT nicht. Als jemand, der in beiden Lagern arbeitet, muss ich sagen, dass in den Abteilungen, in denen Hardware entwickelt wird, leider viel zu oft eine ganz gefährliche Mischung aus "Not Invented Here" und "Habe ich aber immer schon so gemacht" herrscht. Das zieht sich durch den gesamten "Embedded"-Bereich. 73
Die Hardwareentwicklung läuft halt anders als bei den Softwerkern. Bei den Softwerkern gibt es nur eine Richtung src -> exe und glauben, in der Board entwicklung ist es genauso: Schaltplan -> layout -> Fertigungsdaten (i.e. BOM). Aber schon die Richtung Schaltplan -> Layout dreht sich öfters um. Da stellt sich beim entflechten raus, das man die Pins am FPGA über die Bänke swapt um den board-skew einzuhalten. Als zieht der Layouter seine air wires neu und sagt dem Schalktplanzeicher bescheid, das er entsprechend die schaltpläne ediert. Schaltplan <-> layout -> Fertigungsdaten (i.e. BOM). |_________________________________^ Der layouter importiert aber die schematics nicht wieder erneut rein, weil er dann die Teile des layouts die passen, verlieren würde. Aber in der Versionsverwaltung sieht es immer noch so aus als ob die älteren schematics die sourcen für das neuere Layout sind und nicht das ganz neue Schematic eigentlich die Quelle für das aetwas ältere layout ist. ja die zeitlichen Zusammenhänge drehen sich da öfters mal um oder zerfallen in parallele Prozesse die manuell synchronisiert werden. Die Softwerker können sich das nicht vorstellen und schimpfen dann über die Hardwerker die angeblich nicht Rev-Verwaltung verstehen. Dabei ist es eben der "Dokumente-flow" der sich grundsätzlich unterscheidet und um den abzubilden sind die am SW-flow ausgerichten Tools nicht in der Lage.
Ich habe mich aus offensichtlichen Gründen lange gegen das AD365-Konzept gewehrt, aber für mein aktuelles Projekt das erste mal "richtig" eingesetzt und muss sagen: ehrlich gesagt ist das ziemlich gut. Insbesondere, wenn man mit Leuten an verschiedenen Standorten zusammen arbeitet, ist das ganze inkl. Versionskontrolle ziemlich praktisch. Jetzt müsste man nur noch genau so mit dem lokalen git-Server arbeiten können... Viele Grüße Achim
Hans W. schrieb: > Als jemand, der in beiden Lagern arbeitet, muss ich sagen, dass in den > Abteilungen, in denen Hardware entwickelt wird, leider viel zu oft eine > ganz gefährliche Mischung aus "Not Invented Here" und "Habe ich aber > immer schon so gemacht" herrscht. Liegts vielleicht am Alter? HW Entwickler scheinen im Durchschnitt deutlich älter zu sein als SW-Entwickler.
Was da immer alles 'neu erfunden' wird... SVN fuer Hardwareprojekte haben wir schon vor 20 Jahren aufgesetzt. Allerdings ausschliesslich fuer PCB-Tools, die mit ASCII-lesbaren Netzlisten arbeiten (mit Kicad ging das ueber die Jahre ganz gut). Das nette bei SVN ist, dass man sich damit die PCB-Revision auf die Platine ausgeben lassen kann. Bei git ist das etwas muehsamer. Allerdings sollte der Projektmanager einiges an Erfahrung mitbringen, damit ein klarer Prozess definiert ist, sonst wird's schnell zum Gewurschtel. Schliesslich ist es bei mir eine Kombi aus git und SVN geworden, damit auch mit letzterem garantiert eine zentrale Instanz fuers Release zustaendig ist.
Cyblord -. schrieb: >> leider viel zu oft eine >> ganz gefährliche Mischung aus "Not Invented Here" und "Habe ich aber >> immer schon so gemacht" herrscht. > > Liegts vielleicht am Alter? HW Entwickler scheinen im Durchschnitt > deutlich älter zu sein als SW-Entwickler. Eher an der Erkenntnis (die vielleicht erst im Alter kommt), dass Erlernen ein mühseliger Prozess ist und man an effektivsten arbeitet, wenn man auf bestehendem know how aufsetzt. Denn für den neuen Prozessor XYZ samt IDE das erste Blink-Programm zu schreiben geht fix, aber die verplemperte Zeit, weil die DMA Programmierung nicht da stoppt wo man laut Doku glaubt dass sie stoppt, das bezahlt einem keiner. Bestehende Architekturen und Entwicklungsumgebungen erneut zu nutzen "das haben wir schon immer so gemacht" ist also meist die zielführendste Lösung als jeden Tag eine neue Sau durch's Dorf zu treiben (auch eine Art von 'das haben wir schon immer so gemacht', nie ein Projekt zu Ende geführt aber ständig das Pferd gewechselt)
:
Bearbeitet durch User
Michael B. schrieb: > Eher an der Erkenntnis (die vielleicht erst im Alter kommt), dass > Erlernen ein mühseliger Prozess ist und man an effektivsten arbeitet, > wenn man auf bestehendem know how aufsetzt. Man merkt, mit dir geht Fortschritt. svn und git sind jetzt keine kurzlebigen Hypes.
Master of Disaster schrieb: > Dabei ist es eben der "Dokumente-flow" der sich grundsätzlich > unterscheidet und um den abzubilden sind die am SW-flow ausgerichten > Tools nicht in der Lage. Ich glaube, du hast dich nie mit SW Entwicklung in Teams beschäftigt. SW-Entwicklung besteht quasi ausschließlich aus Iterationen. Das ist auch der Grund, warum diese Tools so hilfreich sein können. Aber gut, es gibt nicht "den" Workflow, der für alle passt... zu 99% steht einem in so einer Situation aber dieses "Hab' ich immer schon so gemacht"-Denken im Weg, um seinen eigenen Workflow zu verbessern. Cyblord -. schrieb: > Hans W. schrieb: >> Als jemand, der in beiden Lagern arbeitet, muss ich sagen, dass in den >> Abteilungen, in denen Hardware entwickelt wird, leider viel zu oft eine >> ganz gefährliche Mischung aus "Not Invented Here" und "Habe ich aber >> immer schon so gemacht" herrscht. > > Liegts vielleicht am Alter? HW Entwickler scheinen im Durchschnitt > deutlich älter zu sein als SW-Entwickler. Nein. Das spielt überhaupt keine Rolle. Habe schon mit 30jährigen zu tun gehabt, die SVN für Teufelszeug hielten und 55 jährige, die ohne Repo garnicht erst angefangen haben auch nur einen Finger zu rühren. Tendenziell, je Hardware näher, desto mehr pre-2000 Einstellung und Arbeitsweise. Ich glaube, das liegt einfach daran, dass auf der Hardware du nicht wirklich im Team arbeiten musst. Da macht einer einen Schaltplan, einer das Layout, der nächste simuliert was,... Ich habe einmal im Embedded-SW Bereich bugs in "fremden" Code gefixt. Das war ein Aufstand... statt "danke" für den Patch, gab's eine "Rüge". War/Ist mir unverständlich. Ich hab das beim Debuggen gefunden, der Fix war ein offensichtlicher 2-Zeiler und der Patch ging extra mit "bitte absegnen" markiert and den "Verantwortlichen" von dem Part raus. Bei Schaltplänen hab ich auch ähnliches erlebt. Da scheint sich jeder persönlich angegriffen zu fühlen, wenn irgendjemand etwas kommentiert oder verbessert. Fitzebutze schrieb: > Allerdings sollte der Projektmanager einiges an Erfahrung mitbringen, > damit ein klarer Prozess definiert ist, sonst wird's schnell zum > Gewurschtel. Full ACK. Das hast du aber auch mit Netzlaufwerken udgl. Fitzebutze schrieb: > Schliesslich ist es bei mir eine Kombi aus git und SVN geworden, damit > auch mit letzterem garantiert eine zentrale Instanz fuers Release > zustaendig ist. Wenn ich sowas braucht, dann habe ich eine CI Instanz (meistens Jenkins) am Laufen. Die zieht aus einem Git Repo seine Daten. Da werden dann PCB-Versionen generiert, Firmware signiert,... was halt eben so anfällt und was man an einer Stelle machen möchte (weil z.B. die priv. Keys nur an einer Stelle verfügbar sind) :)
Cyblord -. schrieb: > Man merkt, mit dir geht Fortschritt. > svn und git sind jetzt keine kurzlebigen Hypes. Aber beide der übliche open source Schrott, sie werden nur von den üblichen FanBoys gehypt weil sie kostenlos sind, machen aber Ärger ohne Ende, z.B. Probleme bei Windows/Linux Dateinamen in Gross-kleinschreibung oder Dateidatum. IBM Rational Clearance, Perforce oder PTC Integrity kennt ja keiner dieser Bastler, obwohl sich ein vernünftiges Versionskontrollsystem dadurch auszeichnet, dass es KEINERLEI extra täglichen Arbeitsaufwand (einchecken, Konfliktbearbeitung, pull requests) kostet sondern NUR wenn man mal was nachvollziehen will "wann gab es eigentlich diese Änderung und von wem".
:
Bearbeitet durch User
Michael B. schrieb: > Cyblord -. schrieb: >> Man merkt, mit dir geht Fortschritt. >> svn und git sind jetzt keine kurzlebigen Hypes. > > Aber beide der übliche open source Schrott, sie werden nur von den > üblichen FanBoys gehypt weil sie kostenlos sind, machen aber Ärger ohne > Ende, z.B. Probleme bei Windows/Linux Dateinamen in > Gross-kleinschreibung oder Dateidatum. Genau, deswegen haben sie sich ja auch weltweit durchgesetzt. Michael B. schrieb: > Eher an der Erkenntnis (die vielleicht erst im Alter kommt), dass > Erlernen ein mühseliger Prozess ist und man an effektivsten arbeitet, > wenn man auf bestehendem know how aufsetzt. SVN und git gibts ja eh erst seit ein paar Jahrzehnten. Immer wieder lustig, wie du deine geballte Inkompetenz stolz vor dir her trägst.
Master of Disaster schrieb: > Die Hardwareentwicklung läuft halt anders als bei den Softwerkern. Bei > den Softwerkern gibt es nur eine Richtung src -> exe Oh sweet summer child, so jung und naiv...
Hans W. schrieb: > Wenn ich sowas braucht, dann habe ich eine CI Instanz (meistens Jenkins) > am Laufen. > Die zieht aus einem Git Repo seine Daten. > > Da werden dann PCB-Versionen generiert, Firmware signiert,... was halt > eben so anfällt und was man an einer Stelle machen möchte (weil z.B. die > priv. Keys nur an einer Stelle verfügbar sind) :) Wenigstens einer hier der sein Fach versteht.
Bichael M. schrieb: > Immer wieder lustig, wie du deine geballte Inkompetenz stolz vor dir > her trägst. Immer wieder ein Kennzeichen von Feigheit und Blödheit, wenn du mal wieder einen fake-Namen für deine Beiträge aussuchst. 'Weltweit durchgesetzt', klar, weil kostenlos. Aber das ist kein Zeichen von Qualität
Michael B. schrieb: > Bestehende Architekturen und Entwicklungsumgebungen erneut zu nutzen > "das haben wir schon immer so gemacht" ist also meist die zielführendste > Lösung als jeden Tag eine neue Sau durch's Dorf zu treiben (auch eine > Art von 'das haben wir schon immer so gemacht', nie ein Projekt zu Ende > geführt aber ständig das Pferd gewechselt) Ich glaube, du missverstehst mich da etwas... Hin und wieder muss radikal etwas geändert werden. Dazwischen muss man sehen, was sich inkrementell verbessern lässt. Dabei muss mir jede Änderung auch tatsächlich etwas (also Zeitersparnis) bringen. Welchen Aufwand so eine Änderung bedeuten darf, kann man sich ausrechen, oder bei XKCD nachlesen: https://hackaday.com/2021/05/15/should-i-automate-this/ Michael B. schrieb: > Cyblord -. schrieb: >> Man merkt, mit dir geht Fortschritt. >> svn und git sind jetzt keine kurzlebigen Hypes. > > Aber beide der übliche open source Schrott, sie werden nur von den > üblichen FanBoys gehypt weil sie kostenlos sind, machen aber Ärger ohne > Ende, z.B. Probleme bei Windows/Linux Dateinamen in > Gross-kleinschreibung oder Dateidatum. > > IBM Rational Clearance, Perforce oder PTC Integrity kennt ja keiner > dieser Bastler, obwohl sich ein vernünftiges Versionskontrollsystem > dadurch auszeichnet, dass es KEINERLEI extra täglichen Arbeitsaufwand > (einchecken, Konfliktbearbeitung, pull requests) kostet sondern NUR wenn > man mal was nachvollziehen will "wann gab es eigentlich diese Änderung > und von wem". Also mir ist mittlerweile glaube ich so ziemlich alles was es so gibt über den Weg gelaufen... mit so abartigen Exoten wie dem Microsoft SourceSafe... Gerade die PTC Produkte kannst du als Admin so vermurksen, dass du dich eigentlich NUR mehr mit der Versionierung beschäftigst. Git als "Mist" zu bezeichnen ist da schon ziemlich verwegen... 73
:
Bearbeitet durch User
Michael B. schrieb: > Bichael M. schrieb: >> Immer wieder lustig, wie du deine geballte Inkompetenz stolz vor dir >> her trägst. > > Immer wieder ein Kennzeichen von Feigheit und Blödheit, wenn du mal > wieder einen fake-Namen für deine Beiträge aussuchst. > > 'Weltweit durchgesetzt', klar, weil kostenlos. Aber das ist kein Zeichen > von Qualität Wow, wie toll du argumentieren kannst welche Mängel git denn hat. Und stimmt, in Konzernen mit Millionenbudgets setzt es sich wegen seines Preses durch. Achja, wenn du nicht komplett doof wärst wüsstest du dass üblicherweise genutzte CI-Umgebungen wie Gitlab, Github, Bitbucket oder Azure DevOps keineswegs kostenlos sind. Alter, du musst fachlich echt eine unfassbare Null sein.
Hans W. schrieb: > Git als "Mist" zu bezeichnen ist da schon ziemlich verwegen... Argumente hat er ja eh nicht. Eine klassische Null halt.
git ist mit Sicherheit um Längen professioneller und besser als viele Projekte/Produkte hier. Schwierig ist es tatsächlich das in die Köpfe der Leute zu bekommen, besonders wenn da eingefahre Abläufe geändert werden müssen.
Bichael M. schrieb: > Wow, wie toll du argumentieren kannst welche Mängel git denn hat. Und > stimmt, in Konzernen mit Millionenbudgets setzt es sich wegen seines > Preses durch Gerade dort, was meinst du, an was wir alles sparen. Bichael M. schrieb: > Argumente hat er ja eh nicht Im Gegensatz zu deinem endlosen Palaver habe ich welche genannt: Michael B. schrieb: > Probleme bei Windows/Linux Dateinamen in Gross-kleinschreibung oder > Dateidatum. aber was interessieren dich Fakten, wenn du deinen open source Fanboy-Sermon ablassen musst. Wer nichts anderes kennt...
Michael B. schrieb: > Im Gegensatz zu deinem endlosen Palaver habe ich welche genannt: > > Michael B. schrieb: >> Probleme bei Windows/Linux Dateinamen in Gross-kleinschreibung oder >> Dateidatum. > > aber was interessieren dich Fakten, wenn du deinen open source > Fanboy-Sermon ablassen musst. Wer nichts anderes kennt... Naja, was das bedeuten soll, ist aber zumindest mir schleierhaft. Ich arbeite ausschließlich unter linux. Meine Kunden zu 90% unter Windows. Hatte noch nie Probleme mit Dateinamen... 73
J. S. schrieb: > Schwierig ist es tatsächlich das in die Köpfe der Leute zu bekommen, > besonders wenn da eingefahre Abläufe geändert werden müssen. Insbesonders, wenn es nicht zweckdienlich ist, diese etablierten Abläufe zu ändern/umzustoßen. Schon komisch, das sich die Softwerker denken, das sie mit ihren seit 50 Jahren entwickelten Abläufen für ihre Soft-Engineering könnten sie, die in 100 Jahren entwickelten Abläufe der Hardwareentwicklung gleichwertig ersetzen. Haben halt keine Ahnung vom wirklichen Leben, diese Kellerkinder. Denken halt ein Mensch ist mit: mittag: INPUT Kotelett abends: GOTO Bett adäquat beschrieben ;-)
Wenn man noch mit Klebesymbole arbeitet verstehe ich es durchaus warum man auf Versionsverwaltung verzicht. Die Hardwareentwicklung hat sich in den 100 Jahren hoffentlich weiterentwickelt. ;)
:
Bearbeitet durch User
Michael B. schrieb: > Aber beide der übliche open source Schrott, sie werden nur von den > üblichen FanBoys gehypt weil sie kostenlos sind, machen aber Ärger ohne > Ende, z.B. Probleme bei Windows/Linux Dateinamen in > Gross-kleinschreibung oder Dateidatum. Weder von SVN noch von git kenne ich irgendwelche derartigen Probleme. Beides funktioniert sehr gut. Das dritte VCS, mit dem ich mal arbeiten mußte, war TeamCenter. Der Konzern hat dafür sicherlich ein Vermögen bezahlt und einen dicken Posten "laufende Wartungskosten" gehabt, und trotzdem war es eines der abschreckendsten Werkzeuge die mir je untergekommen sind. Nicht-Intuitiv, funktioniert anders als erwartet, machte unnötige Arbeit, man läuft leicht in Sackgassen aus denen man alleine nicht rauskommt...schrecklich, damit will ich nie wieder zu tun haben. Hans W. schrieb: > Wenn ich sowas braucht, dann habe ich eine CI Instanz (meistens Jenkins) > am Laufen. > Die zieht aus einem Git Repo seine Daten. Jenkins für HW-Entwicklung?? Erzähle bitte mehr darüber.
Michael B. schrieb: > Bichael M. schrieb: >> Wow, wie toll du argumentieren kannst welche Mängel git denn hat. Und >> stimmt, in Konzernen mit Millionenbudgets setzt es sich wegen seines >> Preses durch > > Gerade dort, was meinst du, an was wir alles sparen. Du solltest halt echt mal in der Realität ankommen, erstens weiß jeder der rechnen kann dass sich gut Tools bei Ingenieursstundensätzen von selbst finanzieren, zweitens werden wie oben schon erwähnt üblicherweise kommerzielle git-Implementierungen verwendet, die entgegen deiner Behauptung eben nicht gratis sind. Aber du bemühst dich halt echt zu zeigen, dass du keinerlei Dunst davon hast wie es in Entwicklungsabteilungen aussieht. Wohl eher ein arbeitsloser Alkoholiker der sich die Welt am Stammtisch ausmalt? Michael B. schrieb: > Bichael M. schrieb: >> Argumente hat er ja eh nicht > > Im Gegensatz zu deinem endlosen Palaver habe ich welche genannt: > > Michael B. schrieb: >> Probleme bei Windows/Linux Dateinamen in Gross-kleinschreibung oder >> Dateidatum. Kannst du diese "Argumente" näher ausführen? Wenn du so blöd bist und deine Dateinamenskonventionen zwischen den Plattformen nicht im Griff hast kann echt kein Tool was dafür. Michael B. schrieb: > aber was interessieren dich Fakten, wenn du deinen open source > Fanboy-Sermon ablassen musst. Wer nichts anderes kennt... Süß. Dabei hast scheinbar bis heute nicht mal mitbekommen dass die in Unternehmen verwendeten git-Implementierungen keineswegs gratis oder Open Source sind. Du bist fachlich halt einfach eine kleine Null.
hans schrieb: > Naja, was das bedeuten soll, ist aber zumindest mir schleierhaft. > Ich arbeite ausschließlich unter linux. > Meine Kunden zu 90% unter Windows. > Hatte noch nie Probleme mit Dateinamen... Vermutlich hat er in seinem Leben noch nie mit irgendeinem der genannten Tools gearbeitet und spricht nur vom Hörensagen.... Master of Disaster schrieb: > J. S. schrieb: >> Schwierig ist es tatsächlich das in die Köpfe der Leute zu bekommen, >> besonders wenn da eingefahre Abläufe geändert werden müssen. > > Insbesonders, wenn es nicht zweckdienlich ist, diese etablierten Abläufe > zu ändern/umzustoßen. > > Schon komisch, das sich die Softwerker denken, das sie mit ihren seit 50 > Jahren entwickelten Abläufen für ihre Soft-Engineering könnten sie, die > in 100 Jahren entwickelten Abläufe der Hardwareentwicklung gleichwertig > ersetzen. > > Haben halt keine Ahnung vom wirklichen Leben, diese Kellerkinder. Wow. Wie du außer dümmlichen Gefasel halt einfach keine "Argumente" zu bieten hast.
Thomas P. schrieb: > Wenn man noch mit Klebesymbole arbeitet verstehe ich es durchaus warum > man auf Versionsverwaltung verzicht. Die Hardwareentwicklung hat sich in > den 100 Jahren hoffentlich weiterentwickelt. ;) Vergiss es, das Forum ist ein Haufen von ewiggestrigen (Früh)rentnern, die schon lange nirgends mehr produktiv gearbeitet haben.
Michael B. schrieb: > Cyblord -. schrieb: >> Man merkt, mit dir geht Fortschritt. >> svn und git sind jetzt keine kurzlebigen Hypes. > > Aber beide der übliche open source Schrott, sie werden nur von den > üblichen FanBoys gehypt weil sie kostenlos sind, machen aber Ärger ohne > Ende, z.B. Probleme bei Windows/Linux Dateinamen in > Gross-kleinschreibung oder Dateidatum. Jede IDE, die ich kenne, unterstützt mindestens SVN und git sowieso. Von Hause aus. Altium unterstützt ebenfalls SVN und git, git wird auch in der AD365-Cloud verwendet, und hier bist du längst nicht mehr im Bereich der kostenlosen OS-Software, sondern wirfst große Scheine ein.
hans schrieb: > Naja, was das bedeuten soll, ist aber zumindest mir schleierhaft. So ist das, wenn man im Leben noch nicht ausreichend Erfahrung gesammelt hat. Wühlhase schrieb: > git wird auch in der AD365-Cloud verwendet, und hier bist du längst > nicht mehr im Bereich der kostenlosen OS-Software, sondern wirfst große > Scheine ein. Du siehst, dass auch grosse Firmen, die gierig Schotter wollen, sich gerne bei kostenloser Software bedienen.
Michael B. schrieb: > hans schrieb: >> Naja, was das bedeuten soll, ist aber zumindest mir schleierhaft. > > So ist das, wenn man im Leben noch nicht ausreichend Erfahrung gesammelt > hat. Wie du kleine Lachnummer es einfach nicht schaffst, das angebliche Problem zu beschreiben :) Michael B. schrieb: > Wühlhase schrieb: >> git wird auch in der AD365-Cloud verwendet, und hier bist du längst >> nicht mehr im Bereich der kostenlosen OS-Software, sondern wirfst große >> Scheine ein. > > Du siehst, dass auch grosse Firmen, die gierig Schotter wollen, sich > gerne bei kostenloser Software bedienen. Und wieder stellst du dein absolutes Nicht-Wissen unter Beweis. Hast du überhaupt schon mal aktiv Software entwickelt? Also in einem Unternehmen, nicht im Bastelkeller daheim, und nicht irgendwann mal in den 80ern?
Michael B. schrieb: > Wühlhase schrieb: >> git wird auch in der AD365-Cloud verwendet, und hier bist du längst >> nicht mehr im Bereich der kostenlosen OS-Software, sondern wirfst große >> Scheine ein. > > Du siehst, dass auch grosse Firmen, die gierig Schotter wollen, sich > gerne bei kostenloser Software bedienen. Dann kann es ja aber doch nicht so schlecht sein, wenn Unternehmen das nehemen und weiterverkaufen, hm?
Bichael M. schrieb: > Wie du kleine Lachnummer es einfach nicht schaffst, das angebliche > Problem zu beschreiben :) Hättest du die angesprochenen Produkte intensiv genutzt, wüsstest du um die erwähnten Probleme. Aber unter fake-Namen traust du dir ein Auftreten, mit dem du in der echten Welt die Hosen voll hättest. Bichael M. schrieb: >> Du siehst, dass auch grosse Firmen, die gierig Schotter wollen, sich >> gerne bei kostenloser Software bedienen. > > Und wieder stellst du dein absolutes Nicht-Wissen unter Beweis. So so. Du wolltest sagen: du kannst dir leider gar nicht vorstellen, wie grosse Unternehmen arbeiten, denn du kennst nur H4.
Michael B. schrieb: > Bichael M. schrieb: >> Wie du kleine Lachnummer es einfach nicht schaffst, das angebliche >> Problem zu beschreiben :) > > Hättest du die angesprochenen Produkte intensiv genutzt, wüsstest du um > die erwähnten Probleme. Keine Angst, ich nutz git jeden Tag, im Gegensatz zu anderen hab ich nämlich einen Job. Aber faszinierend, wie du es einfach wieder nicht schaffst eine simple Beschreibung des angeblichen Problems zu liefern. Komisch auch dass der Rest der Welt dieses Problem nicht hat. Vielleicht liegts ja einfach nur daran dass du Nullnummer dir irgendwas ausdenken musst?
Michael B. schrieb: > Bichael M. schrieb: >>> Du siehst, dass auch grosse Firmen, die gierig Schotter wollen, sich >>> gerne bei kostenloser Software bedienen. >> >> Und wieder stellst du dein absolutes Nicht-Wissen unter Beweis. > > So so. > > Du wolltest sagen: du kannst dir leider gar nicht vorstellen, wie grosse > Unternehmen arbeiten, denn du kennst nur H4. Woran genau machst du fest dass ich nicht weiß wie große Unternehmen arbeiten? Du meinst weil ich im Gegensatz zu dir tagtäglich produktiv in einer git-basierten CI-Umgebung arbeite, ohne Probleme, so wie der Rest der Welt auch? Lachnummer.
Versionsverwaltung ist ja schön und nett, aber gibt es auch gute Diff-Tools für Schaltplan und Layout? Und auch Merge-Tools um dann nur manche Änderungen am Layout zu übernehmen.
Wühlhase schrieb: > Hans W. schrieb: >> Wenn ich sowas braucht, dann habe ich eine CI Instanz (meistens Jenkins) >> am Laufen. >> Die zieht aus einem Git Repo seine Daten. > > Jenkins für HW-Entwicklung?? Erzähle bitte mehr darüber. Da sind Scripts mit denen ich Fertigungsdaten generiere und wieder "getagged" eincheck (und dabei den Revisions-Counter entsprechend anpasse.. also eingecheckt ist DEV-xxx, das wird dann in eine "saubere" "Rev Z" am PCB verwandelt und dann als DEV-xxy eingecheckt. Dazu noch scripts die so halb hardware/firmware sind.. z.B. Crypto Key Generierung und Signaturzeug für Bootloader,... Eben dinge, die man lieber zentral erledigt, weil man z.B. die Priv. Keys nicht eincheckt :) Gustl B. schrieb: > Versionsverwaltung ist ja schön und nett, aber gibt es auch gute > Diff-Tools für Schaltplan und Layout? Sogar bei KiCad gibts da schon etwas: https://github.com/leoheck/kiri 73
Michael B. schrieb: > Bichael M. schrieb: >> Wie du kleine Lachnummer es einfach nicht schaffst, das angebliche >> Problem zu beschreiben :) > > Hättest du die angesprochenen Produkte intensiv genutzt, wüsstest du um > die erwähnten Probleme. Sorry aber Michael B. schrieb: > z.B. Probleme bei Windows/Linux Dateinamen in > Gross-kleinschreibung oder Dateidatum. sind ganz eindeutig keine Probleme von Git. Windows, Unix (damit meine ich Linux und Unixe wie Mac-OS) kannst du case-sensitive betreiben, oder auch nicht. Das hängt nicht mit der Software zusammen du du benutzt. Git kann mit beidem umgehen! Das Dateidatum wird von Git nicht verwendet bzw gespeichert. Das ist auch gut so, weil das im Allgemeinen nicht aussagekräftig ist. Git arbeitet mit Änderungen im Repo. Das ist auch das Problem, warum Git für Binärdateien nicht gut geeignet ist. Binäres Diff/Merge funtionieren nur in Sonderfällen zuverlässig. Das ist übrigens auch einer der Gründe, warum ich froh bin, das die Altium Leute mich "vergessen" haben, wie ich Software gesucht habe... Jetzt bin ich voll auf KiCad eingeschossen und will lesbare Libraries, Schematics und Layouts nicht mehr hergeben. Damit geht die Firmware und Hardware Entwicklung jetzt wirklich synchron. Pinout verändert? => gleich in der Firmware mitgeändert und zusammen eingecheckt. Damit ist alles schön nachvollziehbar. 73
Bichael M. schrieb: > Keine Angst, ich nutz git jeden Tag LOL, aber hast noch nicht gemerkt, dass GIT beim auschecken das Dateidatum zerstört. Bichael M. schrieb: > Woran genau machst du fest dass ich nicht weiß wie große Unternehmen > arbeiten Alter, du erzählst unter deinem fake-Namen hier dermassen einen vom Pferd, ROTFL.
Das Datum brauchen nur die Dinosaurier die noch alles in Jahr-Monat-Tag zippen. Weil sie git nicht mehr verstehen (wollen). Was einfach nur unprofessionell ist.
Michael B. schrieb: > LOL, aber hast noch nicht gemerkt, dass GIT beim auschecken das > Dateidatum zerstört. Wie würden sich wohl Build Tools wie make verhalten wenn Git die Dateidaten wiederherstellen würde?
Gustl B. schrieb: > Versionsverwaltung ist ja schön und nett, aber gibt es auch gute > Diff-Tools für Schaltplan und Layout? Und auch Merge-Tools um dann nur > manche Änderungen am Layout zu übernehmen. Ist bei Altium inkludiert. Wer es als schöne Browservariante für Online-Reviews, wie in der Software üblich, haben will, muss den vom TS verlinkten externen Anbieter verwenden.
Michael B. schrieb: > Bichael M. schrieb: >> Keine Angst, ich nutz git jeden Tag > > LOL, aber hast noch nicht gemerkt, dass GIT beim auschecken das > Dateidatum zerstört. Leider schaffst du es in deiner überragenden Fachkompetenz immer noch nicht zu erklären, inwiefern git (schreibt man übrigens klein) das "Dateidatum" (welches?) "zerstört". Vermutlich, weil es dieses Problem nicht gibt, andernfalls wäre es ja den Millionen anderen Nutzern schon aufgefallen. Ursprünglich hast du übrigens von Dateinamen gefaselt, schon vergessen? Michael B. schrieb: > Bichael M. schrieb: >> Woran genau machst du fest dass ich nicht weiß wie große Unternehmen >> arbeiten > > Alter, du erzählst unter deinem fake-Namen hier dermassen einen vom > Pferd, ROTFL. Du kannst also nicht erlären woran du das festmachst, du faselst nur etwas von "Fakenamen", was auch immer das sein soll. Alter, du bist so eine Nullnummer.
S.P. schrieb: > Michael B. schrieb: >> LOL, aber hast noch nicht gemerkt, dass GIT beim auschecken das >> Dateidatum zerstört. > > Wie würden sich wohl Build Tools wie make verhalten wenn Git die > Dateidaten wiederherstellen würde? Ich denke nicht dass er sich über so etwas schon mal Gedanken gemacht hat. Außerdem ist make ja Opensource-Schrott, den eh nur Fanboys verwenden.
Gustl B. schrieb: > Versionsverwaltung ist ja schön und nett, aber gibt es auch gute > Diff-Tools für Schaltplan und Layout? Und auch Merge-Tools um dann nur > manche Änderungen am Layout zu übernehmen. Hab heute mal spaßeshalber mit Chatgpt nen diff Prototypen für eagle xml geschrieben. War recht eindrucksvoll. Nach 2 Stunden hatten wir ein script das die Änderungen der Netze in einem Schaltplan als Liste ausgibt. Mergen sehe ich nicht, es ist kein Problem im xml was zu ändern oder reinzuschreiben. Aber woher soll man wissen was? Bei Software ist die Sprachebene gleich der Funktionsebene, da geht das. Aber ein Schaltplan scheint mir eine Abstraktion zu sein deren Inhalte nichts mit der Funktion zu tun haben.
Bichael M. schrieb: > Leider schaffst du es in deiner überragenden Fachkompetenz immer noch > nicht zu erklären, inwiefern git (schreibt man übrigens klein) das > "Dateidatum" (welches?) "zerstört". Git speichert keine Datei-Metadaten. Also auch nicht das Erstellungsdatum usw. Wenn du neu auscheckst, dann hat die Datei das Datum vom checkout. Wie gesagt, liegt das am grundlegenden Verhalten von git. Das ist by-design so und IMHO auch eine gute Entscheidung gewesen. 73
Hans W. schrieb: > Git speichert keine Datei-Metadaten. der Typ ist auf provo, würde ich ignorieren. hg kümmert sich auch nicht um das Dateidatum. Hat u.a. den Grund das von mehreren Rechnern ein-auschecken möglich ist und der Timesync nicht gewährleistet ist.
Bichael M. schrieb: > Ursprünglich hast du übrigens von Dateinamen gefaselt, schon vergessen? Wenn man einen IQ von nur 10 hat: Michael B. schrieb: > machen aber Ärger ohne Ende, z.B. Probleme bei Windows/Linux Dateinamen > in Gross-kleinschreibung oder Dateidatum. kann man die 2 beispielhaft aufgeführten Probleme halt nicht auseinanderhalten. Bichael M. schrieb: > Vermutlich, weil es dieses Problem nicht gibt Da muss man gar nicht weit suchen Beitrag "GIT und Zeitstempel nach Checkout" Mit jedem Beitrag zeigst du deine Ahnungslosigkeit. Bichael M. schrieb: > Außerdem ist make ja Opensource-Schrott, den eh nur Fanboys verwenden. Noch so eine Ahnungslosigkeit. Make gab es deutlich vor open source. Nur du verwendest vermutlich ein open source make, aber da es bei dir mangels korrekter Dateidatumsangaben eh nur komplette rebuilds gibt, brauchst du eigentlich kein make.
Michael B. schrieb: > aber da es bei dir > mangels korrekter Dateidatumsangaben eh nur komplette rebuilds gibt, > brauchst du eigentlich kein make. Mal angenommen, wir haben ein Repo mit einem älteren Branch (AB) und einem neueren Branch (NB). Der Einfachheit halber unterscheiden sich beide Branches nur durch eine Datei (D). Wir nehmen an, dass der Entwickler das Repo vom Server heruntergeladen hat, NB ausgecheckt hat und mit Make einen Build erstellt hat. Nun checkt der Entwickler AB aus (D wird verändert) und startet Make erneut. Szenario 1: Der originale Zeitstempel von D aus AB wird wiederhergestellt. Szenario 2: Der Zeitstempel von D aus AB wird auf den Zeitpunkt des Auscheckens gesetzt. Preisfrage: Für welches Szenario funktioniert Make korrekt?
Hans W. schrieb: > Bichael M. schrieb: >> Leider schaffst du es in deiner überragenden Fachkompetenz immer noch >> nicht zu erklären, inwiefern git (schreibt man übrigens klein) das >> "Dateidatum" (welches?) "zerstört". > > Git speichert keine Datei-Metadaten. > Also auch nicht das Erstellungsdatum usw. > Wenn du neu auscheckst, dann hat die Datei das Datum vom checkout. > > Wie gesagt, liegt das am grundlegenden Verhalten von git. > Das ist by-design so und IMHO auch eine gute Entscheidung gewesen. Eh, er schafft es nur nicht zu erklären warum das nun ein Problem sein soll. Michael B. schrieb: > Bichael M. schrieb: >> Ursprünglich hast du übrigens von Dateinamen gefaselt, schon vergessen? > > Wenn man einen IQ von nur 10 hat: > > Michael B. schrieb: >> machen aber Ärger ohne Ende, z.B. Probleme bei Windows/Linux Dateinamen >> in Gross-kleinschreibung oder Dateidatum. > > kann man die 2 beispielhaft aufgeführten Probleme halt nicht > auseinanderhalten. Und wieder schaffst du Null es einfach nicht zu erklären wo denn nun das Problem liegen soll und warum der Rest der Welt nicht betroffen ist. Michael B. schrieb: > Bichael M. schrieb: >> Vermutlich, weil es dieses Problem nicht gibt > > Da muss man gar nicht weit suchen > > Beitrag "GIT und Zeitstempel nach Checkout" Und wo soll da nun das Problem liegen, außer dass der halt die gleichen hat wie du? Michael B. schrieb: > Bichael M. schrieb: >> Außerdem ist make ja Opensource-Schrott, den eh nur Fanboys verwenden. > > Noch so eine Ahnungslosigkeit. Make gab es deutlich vor open source. Nur > du verwendest vermutlich ein open source make, aber da es bei dir > mangels korrekter Dateidatumsangaben eh nur komplette rebuilds gibt, > brauchst du eigentlich kein make. Natürlich verwende ich eine OS-Make-Implementierung, so wie die halbe restliche Welt. Wann genau soll es komplette Rebuilds geben? Der Timestamp ändert sich ja nur wenn das jeweilige File geändert wurde, irgendwie scheinst du echt noch nie mit den angesprochenen Tools gearbeitet zu haben. Aber vielleicht schaffst du Nulpe es ja irgendwann doch noch, eine konkrete des angeblichen Problems abzuliefern. In Anbetracht deiner bisherigen Performance allerdings zweifelhaft.
Bichael M. schrieb: > In Anbetracht deiner bisherigen Performance allerdings zweifelhaft. Wer war es, der trotz der genannten Stichworte überhaupt nicht erahnen konnte worum es geht weil er offenkundig nicht mal Anfängerkenntnisse hat, und wer war es, der die beiden genannten Szenarien durcheinander bekommt weil er das Wort 'oder' nicht kennt ? Nur dein fake-Name erlaubt es dir, hier so rumzurotzen, eigene Fehler geflissentlich zu ignorieren. Mit echtem Namen schmeisst dich dein Chef achtkant raus.
J. S. schrieb: > git ist mit Sicherheit um Längen professioneller und besser als viele > Projekte/Produkte hier. > > Schwierig ist es tatsächlich das in die Köpfe der Leute zu bekommen, > besonders wenn da eingefahre Abläufe geändert werden müssen. Das Problem bei Schwachkopf (Idiot, Penner wären andere Übersetzungen von git) ist, dass es genau nur seinen Ablauf kennt oder alles andere mühsam oder gar nicht gebastelt werden kann. Nicht alle arbeiten so oder wollen/können so arbeiten (müssen). Tools sollten dagegen passen, den/die User unterstützen, weder zu viel noch zu wenig tun und flexibel genug sein, um auch bei Änderungen/Umstrukturierungen etc. einsetzbar zu sein oder sie fliegen raus. Kurz: Gute Tools dienen dem/den Usern und nicht umgekehrt. Bei git dienen die User dem Tool.
:
Bearbeitet durch User
Er verzieht keine Mine.Arc N. schrieb: > Kurz: Gute Tools dienen dem/den Usern und nicht umgekehrt. Bei class="hiddenSpellError">git > dienen die User dem Tool. Ok, was verwendest du statt git und warum? Dein Kommentar hat keinerlei konkrete Aussage, was an git schlecht ist. Ich arbeite mit git rein lokal oder mit einem Server. Mit Branches/Merges oder mit einer linearen History wie man es von älteren Programmen kennt. Je nach Projekt und Anforderung sind verschiedene Workflows möglich. Und das hat bei allen Projekten bei mir super funktioniert, mit teilweise hunderten Entwicklern auf einem einzelnen Repository. Man kann jetzt keine Ordner/Dateien global sperren wie bei manch speziellen VCS, aber das ist bei einem verteilten VCS gar nicht möglich durchzusetzen. Und nach meiner praktischen Erfahrung nur in speziellen Fällen sinnvoll.
:
Bearbeitet durch User
Michael B. schrieb: > Bichael M. schrieb: >> In Anbetracht deiner bisherigen Performance allerdings zweifelhaft. > > Wer war es, der trotz der genannten Stichworte überhaupt nicht erahnen > konnte worum es geht weil er offenkundig nicht mal Anfängerkenntnisse > hat, und wer war es, der die beiden genannten Szenarien durcheinander > bekommt weil er das Wort 'oder' nicht kennt ? Leider schaffst du es immer noch nicht in drei Sätzen klar zu erklären, welches Problem du bei git verortest, warum bei mir jedes mal ein kompletter Rebuild notwendig sein soll und warum der Rest der Welt nicht betroffen ist. Kann ja nicht so schwer sein, dein extremes Problem einfach reproduzierbar zu beschreiben? Michael B. schrieb: > Nur dein fake-Name erlaubt es dir, hier so rumzurotzen, eigene Fehler > geflissentlich zu ignorieren. Mit echtem Namen schmeisst dich dein Chef > achtkant raus. Süß. Kannst du mir erklären, welchen Fehler? Ich lern ja gern dazu. Aber vorher bitte eine reproduzierbare Beschreibung deines git-Problems.
Arc N. schrieb: > Bei git > dienen die User dem Tool. Inwiefern? Welche konkreten Kritikpunkte hast du denn? Git ist mit Sicherheit nicht die Krönung der Schöpfung, aber fundierte Kritikpunkte sind ja hioer eher weniger zu finden...
Bichael M. schrieb: > Inwiefern? Welche konkreten Kritikpunkte hast du denn? Git ist mit > Sicherheit nicht die Krönung der Schöpfung, aber fundierte Kritikpunkte > sind ja hioer eher weniger zu finden... Insbesonders wenn man sie nicht die Mühe macht die genannten mal aufzulisten, wie die Umkehr des source -> generated item prinzips. Oder die Probleme wenn man beim Konfig-managment für minimale Änderungen/Adaptionen einen change-Request schreiben muß und die ganze toolchain wieder anwerfen lassen muß. Passiert im Embedded bereich häufiger, Da gibt es eine Maschine die mit anderen grenzwerten für einige Funktionen (bspw. Abschaltgrenze für Kühling) ausgeliefert wird. Da der "offizielle Weg' zu lange dauert, hackt man schnell mit dem Hexeditor das programmierfile -> alles gut. Aber beim nächsten Service, bei dem ein Update aufgespielt wird, vergisst der Techniker das Programmierfile mit den speziellen Konfigwerten zu patchen ...
Wirr ist deiner Worte Sinn. Bei dem ersten Absatz ist nicht mal klar, was das bedeuten soll, beim zweiten ist das kein Problem von git.
Master of Disaster schrieb: > wie die Umkehr des source -> generated item prinzips. Inwiefern? Was wird wann wo umgekehrt? Master of Disaster schrieb: > Oder die Probleme wenn man beim Konfig-managment für minimale > Änderungen/Adaptionen einen change-Request schreiben muß und die ganze > toolchain wieder anwerfen lassen muß. Wie ihr im Unternehmen Changerequests handhabt hat nix, aber auch gar nix damit zu tun ob nun git, SVN oder sonstwas verwendet wird. Und die Toolchain läuft ja hoffentlich vollautomatisch am CI-Server durch, wenn man nur ansatzweise Reproduzierbarkeit garantieren will. Änderung einchecken und am anderen Ende fällt nach ein paar Minuten das Binary raus, fertig. Aber unabhängig davon ob man nun git, SVN oder ZIP-Files verwendet ist es immer und überall eine strunzdoofe Idee, undokumentierte Änderungen reinzukippen. Genau dann passiert nämlich das beschriebene "der Servicetechniker hat vergessen". Master of Disaster schrieb: > Da gibt es eine Maschine die mit anderen grenzwerten für einige > Funktionen (bspw. Abschaltgrenze für Kühling) ausgeliefert wird. Da der > "offizielle Weg' zu lange dauert, hackt man schnell mit dem Hexeditor > das programmierfile -> alles gut. Aber beim nächsten Service, bei dem > ein Update aufgespielt wird, vergisst der Techniker das Programmierfile > mit den speziellen Konfigwerten zu patchen ... Sorry, dass ihr euren Entwicklungsprozess nicht im Griff habt (und offensichtlich auch die Anforderung an eine konfigurierbare Schwelle in der Entwicklung übersehen habt) und deswegen irgendwelche Servicetechniker anfangen in Hexfiles herumzumurksen ist echt nicht die Schuld des Versionierungssystems. Falls bei uns irgendwer anfängt undokumentiert in Binaries herumzupatchen (oder auch ganz beliebt, bei PCBs in der autogenerierten BOM herumpfuschen statt den Schaltplan anzupassen und die Toolchain nochmal durchlaufen zu lassen) gibts was hinter die Löffel und im Wiederholungsfall darf derjenige sich eine neue Klitsche suchen wo solcher Pfusch geduldet wird.
Thomas F. schrieb: > beim zweiten ist das kein Problem von git. Unpopular opinion: wer in einem professionellen Umfeld händisch und undokumentiert in Hexfiles herumfuhrwerkt hat die Kontrolle über sein Leben verloren. Ich bemitleide jetzt schon den armen Entwickler der vorm Gerät sitzt und einfach nicht versteht warum es sich nicht verhält wie im Sourcecode beschrieben.
Beitrag #7327920 wurde vom Autor gelöscht.
Arc N. schrieb: > Das Problem bei Schwachkopf (Idiot, Penner wären andere Übersetzungen > von git) ist, dass es genau nur seinen Ablauf kennt oder alles andere > mühsam oder gar nicht gebastelt werden kann. Nicht alle arbeiten so oder > wollen/können so arbeiten (müssen). > Tools sollten dagegen passen, den User unterstützen, weder zu viel > noch zu wenig tun und flexibel genug sein, um auch bei > Änderungen/Umstrukturierungen etc. einsetzbar zu sein oder sie fliegen > raus. > Kurz: Gute Tools dienen dem/den Usern und nicht umgekehrt. Bei git > dienen die User dem Tool. Nö...bei Open Source-Werkzeugen gilt das nicht, ist zumindest meine Meinung. Der normale Entstehungsweg einer OSS ist: Ein Entwickler hat ein Problem für das er keine (hinreichend befriedigende) Lösung gefunden hat, erschafft diese Lösung und stellt sie aus reiner Großherzigkeit dem Rest der Welt zur Verfügung. Wenn jemand anders ein ähnliches, aber anderes Problem hat, oder dasselbe Problem anders gelöst haben will, dann passt das entwickelte Werkzeug halt nicht und man dann gibt es drei Möglichkeiten: a) Komm damit klar und arbeite mit dem was es bereits gibt. b) Suche dir eine andere Lösung die besser zu deinem Problem passt. c) Löse dein Problem selbst, schreib dein eigenes Programm. d) Heul dich in Foren aus, daß existierende Programme einfach Grütze sind. git wurde ursprünglich mal für die Linuxkernel-Entwickler geschrieben, nach deren Befürfnissen und Anforderungen. Die photosynthesebetriebene eierlegende Wollmilchsau kann es naturgemäß nicht geben, und warum sollte ein Entwickler – der SEIN EIGENES Problem lösen will – es möglichst jedem Recht machen? Unbezahlt? Master of Disaster schrieb: > Bichael M. schrieb: >> Inwiefern? Welche konkreten Kritikpunkte hast du denn? Git ist mit >> Sicherheit nicht die Krönung der Schöpfung, aber fundierte Kritikpunkte >> sind ja hioer eher weniger zu finden... > > Insbesonders wenn man sie nicht die Mühe macht die genannten mal > aufzulisten, wie die Umkehr des source -> generated item prinzips. > > Oder die Probleme wenn man beim Konfig-managment für minimale > Änderungen/Adaptionen einen change-Request schreiben muß und die ganze > toolchain wieder anwerfen lassen muß. Passiert im Embedded bereich > häufiger, > Da gibt es eine Maschine die mit anderen grenzwerten für einige > Funktionen (bspw. Abschaltgrenze für Kühling) ausgeliefert wird. Da der > "offizielle Weg' zu lange dauert, hackt man schnell mit dem Hexeditor > das programmierfile -> alles gut. Aber beim nächsten Service, bei dem > ein Update aufgespielt wird, vergisst der Techniker das Programmierfile > mit den speziellen Konfigwerten zu patchen ... Ohne das Problem näher zu kennen wäre das ein Fall für parallele Branches, je ein Branch für so unterschiedliche Maschinen. Jedenfalls könnte man das Problem in git so lösen. Daß der offizielle Weg "zu lange" dauert ist aber kein Problem der Versionsverwaltung und ich würde auch sagen kein Problem der Werkzeuge überhaupt, und es ist als letztes ein Problem des Servicetechnikers (der hat nix "vergessen"), sondern einfach nur dein eigenes. Und wer dann solche Abkürzungen nimmt wie du beschreibst, der hat in der Entwicklung m.M.n. nichts verloren. Bichael M. schrieb: > Thomas F. schrieb: >> beim zweiten ist das kein Problem von git. > > Unpopular opinion: wer in einem professionellen Umfeld händisch und > undokumentiert in Hexfiles herumfuhrwerkt hat die Kontrolle über sein > Leben verloren. > Ich bemitleide jetzt schon den armen Entwickler der vorm Gerät sitzt und > einfach nicht versteht warum es sich nicht verhält wie im Sourcecode > beschrieben. Genau so ist es. Wobei ich das mit dem Umfeld nicht auf den professionellen (=gewerblichen) Bereich einschränken würde.
Wühlhase schrieb: > Daß der offizielle Weg "zu lange" dauert ist aber kein Problem der > Versionsverwaltung und ich würde auch sagen kein Problem der Werkzeuge > überhaupt, Es ist ein Problem der Softwareentwicklung als prozess das sie nicht in der Lage für verschiedene Konfiguration zeitnah passende Software zu liefern. da hat halt der projektmanager oder wer auch immer nicht an dieses Alltagsszenario gedacht und nun müßen es die Techniker an der "front" ausbaden > und es ist als letztes ein Problem des Servicetechnikers (der > hat nix "vergessen"), sondern einfach nur dein eigenes. Und wer dann > solche Abkürzungen nimmt wie du beschreibst, der hat in der Entwicklung > m.M.n. nichts verloren. naja die Alternative ist es, den job zu verlieren wenn man nicht bereit ist diese Abkürzung in der Produktauslieferung zu nehmen sondern die "Arschkarte" an den Entwickler per feature-request zurück reicht. Hätte man sich vorher Möglichkeiten des Konfigmanagments im feld überlegt oder wäre man in der Lage saubere Software innerhalb weniger stunden zu liefern bräuchte man die Abkürzung 'cat /dev/console >> /mem/kernel' nicht ;-) > Ich bemitleide jetzt schon den armen Entwickler der vorm Gerät sitzt und > einfach nicht versteht warum es sich nicht verhält wie im Sourcecode > beschrieben. Verschwendetes Mitleid. Ein Programmierer im Embedded, der nicht in der Lage ist einen binärvergleich seines Compilates mit dem Firmwar-ROM durchzuführen hat es nicht anders verdient. Wozu gibt es versionsnummern und hashes?!
Master of disaster schrieb: > naja die Alternative ist es, den job zu verlieren wenn man nicht bereit > ist diese Abkürzung in der Produktauslieferung zu nehmen sondern die > "Arschkarte" an den Entwickler per feature-request zurück reicht. Hätte > man sich vorher Möglichkeiten des Konfigmanagments im feld überlegt oder > wäre man in der Lage saubere Software innerhalb weniger stunden zu > liefern bräuchte man die Abkürzung 'cat /dev/console >> /mem/kernel' > nicht ;-) Wenn mein Job daran hinge, solche Pfuschgriffe zu akzeptieren weil dir Fa. nicht in der Lage ist, Prozesse an die Bedürfnisse und Gegebenheiten anzupassen, würde ich ernsthaft anfangen Bewerbungen zu schreiben. Ich meine, sowas ist doch nur ein steter Quell vermeidbaren Ärgers.
Master of disaster schrieb: > Wühlhase schrieb: >> Daß der offizielle Weg "zu lange" dauert ist aber kein Problem der >> Versionsverwaltung und ich würde auch sagen kein Problem der Werkzeuge >> überhaupt, > > Es ist ein Problem der Softwareentwicklung als prozess das sie nicht in > der Lage für verschiedene Konfiguration zeitnah passende Software zu > liefern. > da hat halt der projektmanager oder wer auch immer nicht an dieses > Alltagsszenario gedacht und nun müßen es die Techniker an der "front" > ausbaden Es ist nicht das Problem "der Softwareentwicklung", es ist das Problem eurer Softwareentwicklung. Bekommt halt euren Prozess in den Griff. Master of disaster schrieb: > naja die Alternative ist es, den job zu verlieren wenn man nicht bereit > ist diese Abkürzung in der Produktauslieferung zu nehmen sondern die > "Arschkarte" an den Entwickler per feature-request zurück reicht. Hätte > man sich vorher Möglichkeiten des Konfigmanagments im feld überlegt oder > wäre man in der Lage saubere Software innerhalb weniger stunden zu > liefern bräuchte man die Abkürzung 'cat /dev/console >> /mem/kernel' > nicht ;-) Warum genau soll der Servicetechniker den Job verlieren wenn die Entwicklung den Prozess verkackt? Einfach unerledigter Dinge nach Hause fahren mit Hinweis darauf dass es halt nicht geht, dann wird die Geschäftsführung der Entwicklung schon Beine machen. Einfach so undokumentiert am Binary herumpfuschen statt den Prozess zu verbessern ist die dämlichste Variante von allen, aber wem das nicht einleuchtet hats eh nicht anders verdient. Da merkt man schon warum jemand in so einer Pfuschbude arbeitet. Master of disaster schrieb: > Verschwendetes Mitleid. Ein Programmierer im Embedded, der nicht in der > Lage ist einen binärvergleich seines Compilates mit dem Firmwar-ROM > durchzuführen hat es nicht anders verdient. Wozu gibt es versionsnummern > und hashes?! Dass Versionsnummern wertlos sind, wenn da irgendwer im Binary herummurkst, ist dir ja hoffentlich selbst klar. Und warum sollte der Entwickler überhaupt auf die Idee kommen die Firmware auszulesen und mit dem Original zu vergleichen? Rechnet ja keiner damit dass da irgendein Volldepp am Binary herumpfuscht. Wühlhase schrieb: > Wenn mein Job daran hinge, solche Pfuschgriffe zu akzeptieren weil dir > Fa. nicht in der Lage ist, Prozesse an die Bedürfnisse und Gegebenheiten > anzupassen, würde ich ernsthaft anfangen Bewerbungen zu schreiben. Naja, dass er lieber herumpfuscht (und das nicht mal für andere nachvollziehbar dokumentiert, so dass beim nächsten Mal wieder das gleiche Problem auftaucht), anstatt es einfach nach oben zu eskalieren und so für langfristige Verbesserung zu sorgen, sagt ja eh schon alles. So jemand will ja gar nirgends anders hin. Oder die anderen wollen ihn nicht. Ich würd mich auch bedanken wenn einer unserer Techniker eigenmächtig herumpfuscht und damit jegliche Prozesssicherheit zerstört anstatt einfach Feedback in die Entwicklung zu geben. Der wär ganz schnell wieder weg...
Bichael M. schrieb: > Ich würd mich auch bedanken wenn einer unserer Techniker eigenmächtig > herumpfuscht und damit jegliche Prozesssicherheit zerstört anstatt > einfach Feedback in die Entwicklung zu geben. Und zumindest bei mir würde solches Feedback auf jedenfall dankbar aufgenommen werden. Es sind sich nicht alle Ingenieure zu fein, auch mit Technikern auf Augenhöhe zu reden. ;)
Bichael M. schrieb: > Naja, dass er lieber herumpfuscht (und das nicht mal für andere > nachvollziehbar dokumentiert, so dass beim nächsten Mal wieder das > gleiche Problem auftaucht), anstatt es einfach nach oben zu eskalieren > und so für langfristige Verbesserung zu sorgen "... langfristig ...", eben. Jetzt mal ehrlich, wie lange dauert es, eine solche Änderung als Featurerequest über die nächsten regel.meetings ins Projektmanagment hochzu-eskalieren, HW-Konfigurationsspezifische Firmware zu bauen und für die Produktion freizugeben? Erschwerend kommt vielleicht noch die Urlaubsphase hinzu? Und wer meint sowas kommt nicht vor, mal ein so ähnlich tatsächlich passierte Situation: Auf dem Platine sind standardmäßig Spannungsmonitor-IC vorgesehen, die die vielen Betriebsspannungen überwachen. Die Firmware liest die Monitore aus (SPI) und steuert entsprechend den Health status des Boards. Ist der Monitor-Chip nicht auslesbar blockiert die Firmware die Baugruppe. Funktioniert wunderbar, die Erfahrung zeigt, das dieses Monitoring eigentlich unnötig ist. Jetzt steht die Produktion neuer Boards an, die Lieferung der Monitor-Chips fällt aber im letzten Moment aus ... es müssen also ungeplanter Weise Boards ohne diesen Monitorchip ausgeliefert werden. Wie gesagt, auch ohne diese Chips tut das board, wenn die Software nur will. Eine Nachbestückung ist aus technologischen Gründen (Platine in Anlage verbaut und Anlage wird in die Pampa verschickt) nicht möglich/vorgesehn. Wie lange dauert es jetzt, das die (externe) Softwareabteilung eine qualifizierte Variante für diese partiell bestückten Boards zuschickt? Weiter erschwerend kommt vielleicht hinzu, das die (externe) Softwarehütte auf Neu-beauftragung besteht, also der Einkauf erst mal einen Auftrag "auslösen" muß und Finance die Gelder dafür freigeben muß. Und natürlich darf diese Firmware-Änderung nicht für Boards mit bestückten Spannungsmonitor verwendet werden, Produkt-managment muss also für eine neue baugruppenuntervariante neu eine interne Typnummer ziehen, die ins SAP eingepflegt werden muß .... Also, wie lange dauert der "saubere" Durchlauf (Änderung, comüpilat, Regression tests,...) für diese Änderung ? Meine Schätzung, wenn alles glatt läuft, Minimum eine Woche, realistisch 3-4 Wochen. Nicht das ich mich gegen einen sauberen Prozess sperren würde, allerdings ist manchen nicht klar, was die Floskel "langfristig" in Echt bedeudet. Ist halt wie bei der Uni, verpasst man den Prüfungstermin um 30 Minuten, verschiebt sich das Ganze gleich um ein Semester.
Master of disaster schrieb: > Jetzt mal ehrlich, wie lange dauert es, eine solche Änderung als > Featurerequest über die nächsten regel.meetings ins Projektmanagment > hochzu-eskalieren, HW-Konfigurationsspezifische Firmware zu bauen und > für die Produktion freizugeben? Erschwerend kommt vielleicht noch die > Urlaubsphase hinzu? Wenn die Geschäftsführung einen Anruf vom Kunden bekommt dass der Termin nicht hält geht sowas erfahrungsgemäß ziemlich schnell. Wenn man hingegen immer alles irgendwie hinpfuscht wirds halt für immer so bleiben. Kein Mitleid. Master of disaster schrieb: > Funktioniert wunderbar, die Erfahrung zeigt, das dieses Monitoring > eigentlich unnötig ist. "Eigentlich unnötig", herrlich. Master of disaster schrieb: > Jetzt steht die Produktion neuer Boards an, die Lieferung der > Monitor-Chips fällt aber im letzten Moment aus ... Echt faszinierend, dass du nur in Buden zu landen scheinst die ihre Prozesse von vorn bis hinten nicht im Griff haben. Master of disaster schrieb: > Meine Schätzung, wenn alles glatt läuft, Minimum eine Woche, realistisch > 3-4 Wochen. Ideal, dann lernt der Verantwortliche gleich mal nachhaltig, die Bauteilbestellung beim nächsten mal nicht zu verkacken. Master of disaster schrieb: > Nicht das ich mich gegen einen sauberen Prozess sperren würde, > allerdings ist manchen nicht klar, was die Floskel "langfristig" in Echt > bedeudet. Offensichtlich ist dir die Bedeutung des Wortes "langfristig" nicht bekannt. Tipp: nicht das was du denkst. Aber gut, war ja auch nicht anders zu erwarten. Und wenn sie nicht gestorben sind, dann pfuschen sie noch heute... Stell dir vor, es gibt ganz ganz viele Firmen, die machen Safetyzeugs für Automotive, Industrial oder Medical, die schaffens auch ohne so peinliche Pfuschlösungen. Komisch, was? Master of disaster schrieb: > Also, wie lange dauert der "saubere" Durchlauf (Änderung, comüpilat, > Regression tests,...) für diese Änderung ? Selbst einfach nur mit dem auskommentierten Funktionsaufruf bauen und die Tests erst im Nachgang laufen lassen wär professioneller als dein absurdes herumgepfusche, und würd auch nicht länger dauern.
Vn N. schrieb: > Wenn man hingegen immer alles irgendwie hinpfuscht wirds halt für immer > so bleiben. Kein Mitleid. > "Eigentlich unnötig", herrlich. > Echt faszinierend, dass du nur in Buden zu landen scheinst die ihre > Prozesse von vorn bis hinten nicht im Griff haben. > Offensichtlich ist dir die Bedeutung des Wortes "langfristig" nicht > bekannt. Tipp: nicht das was du denkst. > Aber gut, war ja auch nicht anders zu erwarten. > Und wenn sie nicht gestorben sind, dann pfuschen sie noch heute... > > Stell dir vor, es gibt ganz ganz viele Firmen, die machen Safetyzeugs > für Automotive, Industrial oder Medical, die schaffens auch ohne so > peinliche Pfuschlösungen. Komisch, was? > die Tests erst im Nachgang laufen lassen wär professioneller als dein > absurdes herumgepfusche, und würd auch nicht länger dauern. Sonderlich hilfreich ist dein Pamphlet nicht.
Wie du halt einfach kein einziges Gegenargument liefern kannst auf meine Ausführungen, warum im Binary herumpfuschen sinnlos und dumm ist. Lustig.
Master of disaster schrieb: > Jetzt mal ehrlich, wie lange dauert es, eine solche Änderung als > Featurerequest über die nächsten regel.meetings ins Projektmanagment > hochzu-eskalieren, HW-Konfigurationsspezifische Firmware zu bauen und > für die Produktion freizugeben? Erschwerend kommt vielleicht noch die > Urlaubsphase hinzu? Warum latschst du nicht mal mit einer Kaffeetasse in der Hand ins Entwicklungsbüro, fragst wer für was zuständig ist und schilderst dem einfach mal die Situation bei euch? Vielleicht haben die euer Problem bereits gelöst und bei euch ist es einfach nur noch nicht angekommen. Da arbeiten doch hoffentlich nicht nur Idioten. Master of disaster schrieb: > Und wer meint sowas kommt nicht vor, mal ein so ähnlich tatsächlich > passierte Situation: > > Auf dem Platine sind standardmäßig Spannungsmonitor-IC vorgesehen, die > die vielen Betriebsspannungen überwachen. Die Firmware liest die > Monitore aus (SPI) und steuert entsprechend den Health status des > Boards. Ist der Monitor-Chip nicht auslesbar blockiert die Firmware die > Baugruppe. > > Funktioniert wunderbar, die Erfahrung zeigt, das dieses Monitoring > eigentlich unnötig ist. > > Jetzt steht die Produktion neuer Boards an, die Lieferung der > Monitor-Chips fällt aber im letzten Moment aus ... es müssen also > ungeplanter Weise Boards ohne diesen Monitorchip ausgeliefert werden. > Wie gesagt, auch ohne diese Chips tut das board, wenn die Software nur > will. Eine Nachbestückung ist aus technologischen Gründen (Platine in > Anlage verbaut und Anlage wird in die Pampa verschickt) nicht > möglich/vorgesehn. Ehrlich: Das ist absolut kein Problem, das irgendein Techniker zu lösen hat. Das haben Einkauf/Fertigung verkackt, Lösen können es kurzfristig die Softwareentwickler, aber wie sollen sie es mitbekommen und sich darum kümmern wenn sie nicht wissen daß es ein Problem gibt? Hast du dir jemals Gedanken darüber gemacht, wie dein Nachfolger mit dem zurecht kommen soll was du da gebaut hast? Wenn du clever bist, nutzt du das jetzt um eine saftige Gehaltserhöhung einzufordern.
Wühlhase schrieb: > Wenn du clever bist, nutzt du > das jetzt um eine saftige Gehaltserhöhung einzufordern. Könnte aber auch passieren dass er statt einer Gehaltserhöhung einen ordentlichen Einlauf verpasst bekommt wenn er stolz erzählt wie er in den Firmwareimages undokumentiert herumfuhrwerkt...
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.