Forum: Platinen Git for hardware


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Wühlhase (Gast)


Lesenswert?

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

von db8fs (Gast)


Lesenswert?

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.

von Master of Disaster (Gast)


Lesenswert?

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.

von Wühlhase (Gast)


Lesenswert?

Master of Disaster schrieb:
> Ich werde mich nicht sicher nicht registrieren

Was hindert dich daran, als Namen Bart Simpson anzugeben?

von Mucky F. (Gast)


Lesenswert?

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.

von Joe J. (j_955)


Lesenswert?


von Joe J. (j_955)


Lesenswert?

Für einen Hardwörker ist es von Vorteil, wenn man Google als 
Suchmaschine benutzen kann;-)

von Master of disaster (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

Bist du mit W.S. verwandt?
Git ist ein Programm zur Versionsverwaltung, darin kann man nichts 
abkippen.

von Cyblord -. (cyblord)


Lesenswert?

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
von Joe J. (j_955)


Lesenswert?

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?

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

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

von Master of Disaster (Gast)


Lesenswert?

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.

von Joachim S. (electribe)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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.

von Fitzebutze (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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
von Cyblord -. (cyblord)


Lesenswert?

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.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

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) :)

von Michael B. (laberkopp)


Lesenswert?

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
von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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...

von Bichael M. (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

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
von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

Hans W. schrieb:
> Git als "Mist" zu bezeichnen ist da schon ziemlich verwegen...

Argumente hat er ja eh nicht. Eine klassische Null halt.

von J. S. (jojos)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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...

von hans (Gast)


Lesenswert?

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

von Master of Disaster (Gast)


Lesenswert?

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 ;-)

von Thomas P. (pointhi)


Lesenswert?

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
von Wühlhase (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.

von Wühlhase (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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?

von Wühlhase (Gast)


Lesenswert?

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?

von Michael B. (laberkopp)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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?

von Bichael M. (Gast)


Lesenswert?

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.

von Gustl B. (gustl_b)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

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

von Michael B. (laberkopp)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von S.P. (Gast)


Lesenswert?

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?

von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.

von Mucky F. (Gast)


Lesenswert?

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.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

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

von Mucky F. (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von S.P. (Gast)


Lesenswert?

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?

von Bichael M. (Gast)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von Arc N. (arc)


Lesenswert?

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
von Thomas P. (pointhi)


Lesenswert?

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
von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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...

von Master of Disaster (Gast)


Lesenswert?

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 ...

von Thomas F. (tommf)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.

von Bichael M. (Gast)


Lesenswert?

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.
von Wühlhase (Gast)


Lesenswert?

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.

von Master of disaster (Gast)


Lesenswert?

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?!

von Wühlhase (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.