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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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...
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.
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.
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)
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.
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.
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.
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) :)
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".
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.
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.
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) :)
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/
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...
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.
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.
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...
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:
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. ;)
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.
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?
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.
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.
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....
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.
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.
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.
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.
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?
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?
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?
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?
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.
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 :)
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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...
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 ...
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".
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.
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.
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?
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.
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.
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?!
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.
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.
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.
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.
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...
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. ;)
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.
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.
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?
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.
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.
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.
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.
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...
