it-swarm.com.de

Beste Versionskontrollgewohnheiten für Solo-Entwickler?

Ich bin ein alleiniger Entwickler bei meiner Arbeit und verstehe die Vorteile von VCS. Es fällt mir schwer, mich an gute Praktiken zu halten. Im Moment verwende ich git, um hauptsächlich Web-Apps zu entwickeln (die aufgrund meiner Arbeit niemals Open Source sein werden).

Mein aktueller Workflow besteht darin, viele Änderungen an der Entwicklungssite vorzunehmen, zu testen, zu überarbeiten, zu testen, glücklich zu sein und Änderungen festzuschreiben und dann die Festschreibung auf die Live-Site zu übertragen (wenn ich also an einer großen neuen Änderung arbeite, kann ich nur einmal pro Woche festschreiben; aber mein IDE hat eine gute Rückgängig-Historie für nicht festgeschriebene Sachen).

Grundsätzlich verwende ich git nur beim Umschalten zwischen Maschinen (z. B. Arbeitsentwicklungscomputer zu Heimentwicklungscomputer oder zu Live-Maschine), aber tagsüber sehe ich den Vorteil nicht wirklich. Dies führt dazu, dass ich lange Wäschelisten mit Änderungen habe (und ich habe Probleme, für jedes Commit eine gute Nachricht zu finden; und wenn ich in Eile bin - neige ich dazu, beschissene Nachrichten wie "verschiedene Änderungen an Administrator und Vorlagen" zu hinterlassen).

Wie oft sollte ich mich verpflichten? Sollte jede einzeilige Änderung ein Commit erhalten? Sollte ich mich vor einem Test festlegen (z. B. zumindest für Syntax-/Kompilierungsfehler und muss ihn dann vollständig rückgängig machen; da die Idee nicht funktioniert hat oder die Nachricht eine Lüge ist)?

Sollte ich sicherstellen, dass ich mich jeden Morgen/Nachmittag verpflichte, bevor ich aufhöre, zum Abendessen zu arbeiten, solange es noch frisch ist? Was verpasse ich durch schlechte VCS-Gewohnheiten?

36
dr jimbob

Sie vermissen viel.

In gewisser Weise bin ich auch solo. Ich verpflichte mich jedes Mal, wenn ich eine signifikante Änderung vornehme oder bevor ich eine signifikante Änderung beginne, damit ich zurückgehen kann, wenn ich Dinge vermassle, und hin und wieder, auch wenn ich nichts Großes mache. Nicht wirklich jeden Tag, aber nah. Manchmal ein paar Mal am Tag.

Was ich bekomme ist, dass ich jederzeit zurückkehren kann. Welches ist viel. Auch die Bestellung der Filialen hilft.

Ich denke, es gibt mir viel Ordnung.

Ich benutze svn und habe es satt. Aber ich kann nicht mehr Zeit damit verbringen, etwas anderes zu lernen.

Viel Glück.

24
cauchy

Sie sollten oft begehen. Sie sollten sich auf jeden Fall verpflichten, nachdem Sie einen logischen Meilenstein erreicht haben. Wenn dies länger als einen Tag dauert, sollten Sie sich zumindest am Ende Ihres Arbeitstages verpflichten oder, noch besser, Ihre Arbeit in kleinere Teile aufteilen.

Dafür gibt es viele Gründe. Was ist zum Beispiel, wenn Ihr Computer abstürzt? Es ist viel besser, nur einen Tag Arbeit zu verlieren als eine Woche oder einen Monat. Ein weiterer Grund ist, dass häufige Commits das Isolieren eines Fehlers erleichtern. Sie können eine binäre Suche durchführen und herausfinden, welche kleine Änderung den Fehler verursacht hat.

Eine andere Sache: Bevor Sie sich verpflichten, sollten Sie einen Unterschied machen und sich alle Änderungen ansehen, die Sie vorgenommen haben. Auf diese Weise können Sie überprüfen, ob alle Änderungen sinnvoll sind und ob Sie nichts vergessen haben. Dies hilft Ihnen auch dabei, eine bessere Commit-Nachricht zu erstellen. Und dies ist natürlich ein weiterer Grund, sich häufig zu engagieren: Es ist viel einfacher, die Änderungen eines Tages durchzugehen als den Wert eines Monats.

18
Dima

Um CVS optimal zu nutzen, sollten Sie jeweils an einer Funktion/Fehlerbehebung arbeiten und festschreiben, wann diese Funktion/Fehlerbehebung abgeschlossen ist. Auf diese Weise erhalten Sie:

  • commit-Nachrichten sind einfacher zu erstellen und sinnvoller.
  • einfachere Verfolgung zukünftiger Fehler zurück zu den Änderungen, die sie eingeführt haben;
  • einfacheres Zurücksetzen auf einen vorherigen Status (selbst wenn dies bedeutet, dass eine fehlgeschlagene Funktion verloren geht, aber die danach aufgetretenen Fehlerkorrekturen beibehalten werden).

Da Sie zwischen PCs wechseln, sollten Sie mindestens zwei Zweige haben:

  • ein "Ready to go" -Zweig, der immer funktioniert (mit Ausnahme der Fehler, an denen Sie im Entwicklungszweig arbeiten, natürlich).
  • ein Entwicklungszweig, der sich von Zeit zu Zeit in einem nicht lauffähigen Zustand befindet (wie während Ihrer Heimreise von der Arbeit;).
10
Ethan Furman

Sollte jede einzeilige Änderung ein Commit erhalten?

Wenn dies das ist, was einen Fehler behebt, sicher.

Was verpasse ich durch schlechte VCS-Gewohnheiten?

Ich habe mit einem Mann gearbeitet, der "schlechte VCS-Gewohnheiten" hatte. Er liebte es, ganz alleine zu arbeiten, und er war verantwortlich für eine Produktlinie, die ungefähr 1.000.000 USD/Jahr einbrachte. Er würde sich nur verpflichten, wenn der Chef ihn nörgelte. Dann stürzte eines Tages seine Festplatte ab. Nachdem wir einen Ersatz für ihn eingerichtet hatten, stellten wir fest, dass sein letzter Check-in 6 Monate zuvor war. Da das VCS Source Safe war, können Sie erraten, was sonst noch schief gelaufen ist - das letzte Commit war beschädigt. Wir mussten mehr als ein Jahr zurückgehen, um eine nicht beschädigte Version seiner Produktlinie zu erhalten. Er wurde nicht gefeuert, obwohl er hätte sein sollen.

Eine andere Anekdote betrifft mich. Ich habe Code für Hobby- und Forschungsprojekte auf austauschbaren Festplatten gespeichert. Eines Tages wurde in meine Wohnung eingebrochen. Der Laptop (der kaputt war) und alle austauschbaren Festplatten wurden gestohlen. Jede DVD (mit Ausnahme von Red Dawn) wurde gestohlen. Keiner der Desktop-Computer wurde gestohlen. Wenn ich eine externe Quellcodeverwaltung hätte, hätte ich keine Projekte im Wert von 15 Jahren verloren, zumal einige auf akademischen Projekten beruhten - viele der Profis verließen die Akademie, um in die Privatindustrie zu gehen, sodass diese Projekte in einem IP-Loch für Unternehmen verschwanden, das das verlorener Code kann nicht wiederhergestellt werden.

Wie oft sollte ich mich verpflichten?

Ich zerlege es in ein paar Metriken:

  • Wie viel Arbeit sind Sie bereit zu verlieren, wenn Ihr Computer stirbt? oder wird gestohlen?

  • Wenn dies Bug_1234 behebt, checken Sie den Code mit dem Kommentar "behebt Bug_1234" ein.

  • Wenn dies eine logische Übermittlung/ein logischer Meilenstein ist, checken Sie ihn mit einem Kommentar wie "Bug_1234, form_xyz" (oder Task_1234) ein.

  • Checken Sie den Code immer am Freitagabend ein, bevor Sie nach Hause fahren. Machen Sie auch einen Check-in (oder machen Sie die Kasse rückgängig) von allem, bevor Sie in den Urlaub fahren.

  • Wann immer es die Unternehmensrichtlinien vorschreiben.

7
Tangurena

Denken Sie nicht an die Anzahl der Zeilenänderungen. Denken Sie in Funktionsblöcken. Mit VCS können Sie für jeden Funktionsblock eine Überschrift an einer zentralen Stelle angeben, damit Sie leicht sehen können, was hier passiert ist, z. Git Log.

Mit IDEs wie Eclipse können Sie auch auf eine bestimmte Linie zeigen und zu dem Commit wechseln, das sie in die angezeigte Form gebracht hat. Mit anderen Worten, Sie können direkt von einer Quellzeile zum Commit wechseln. Wenn das Commit klein ist und eine gute Nachricht enthält, ist es viel hilfreicher als "Tonnen von Fehlern behoben".

5
user1249

Ich würde sagen, das größte Problem, das Sie verpassen, wenn Sie Änderungen so gruppieren, ist die Möglichkeit, festzustellen, wann und wo Fehler eingeführt wurden.

Nach meiner Erfahrung gab es einige Male, in denen zwei bis drei Wochen nach seiner Einführung ein Fehler festgestellt wurde und es so lange nachträglich schwierig ist, die Commits einer Woche zu sichten. In diesen Fällen war es hilfreich, die Commits einfach binär zu durchsuchen, um festzustellen, welche individuelle Änderung das Problem verursacht hat. Diese Fehler waren hauptsächlich Speicherauslastungsfehler in C++ - Code, sodass sie bei Ihrem Projekt möglicherweise nicht so häufig auftreten.

Weitere Vorteile kommen bei der Entwicklung in einem Team zum Tragen - einfache Commit-Kommentare, einfachere Zusammenführungen, das Beziehen von Commits auf Fehlerkorrekturen usw.

Ich würde mit Ihrem Workflow vermuten, dass Sie Tags oder Lesezeichen verwenden müssen, um zu verfolgen, welche Codeversion auf der Live-Site verwendet wird, wenn Sie täglich oder halb täglich festschreiben. Ich würde sagen, das ist das Wichtigste, um den Überblick zu behalten.

4
tugs

Ich bin auch ein Solo-Entwickler, ich benutze SVN und ich liebe es. Ich habe sogar ein Tool geschrieben, um die Struktur meiner Datenbank und die darin enthaltenen Testdaten in XML zu konvertieren, damit ich diese in die Quellcodeverwaltung einbeziehen kann.

Ich verpflichte mich normalerweise immer dann, wenn ich eine autonome Arbeitseinheit abgeschlossen habe. Wenn ich hier und da eine Reihe trivialer und nicht verwandter einzeiliger Korrekturen durchführe, lege ich manchmal alle zusammen fest. Wenn jedoch ein einzeiliger Fix zwischen zwei nicht zusammenhängenden großen autonomen Arbeitseinheiten auftritt, erhält er seine eigenen begehen, daran ist nichts auszusetzen.

Außerdem schreibe ich immer Code fest, der kompiliert wird, und fast immer Code, der auch alle grundlegenden Tests besteht. Wenn nicht, stelle ich sicher, dass die Festschreibungsnachricht "DOES NOT WORK" enthält. Der einzige Fall, in dem dies geschieht, ist, wenn ich wichtige Änderungen vorgenommen habe, die ich nicht verlieren möchte, obwohl sie noch nicht ganz funktionieren, und obendrein bin ich im Begriff, ein großartiges Refactoring-Abenteuer zu beginnen, bei dem ich mir nicht sicher bin, ob es wird erfolgreich sein. Also benutze ich das Repository als Backup der Arbeit, die ich bisher geleistet habe, bevor ich riskiere, es durcheinander zu bringen und wegzuwerfen.

Dies bedeutet, dass ich immer festschreibe, wenn mein Quellcode festgeschrieben werden muss. Es macht absolut keinen Sinn, Regeln für das Festschreiben am Morgen oder am Abend festzulegen. Es ist der Zustand, in dem sich der Code befindet, der vorschreibt, ob es Zeit zum Festschreiben ist oder nicht.

Die Nachrichten, die Sie in das Repository stellen, spielen keine große Rolle. Wenn Sie absolut nichts Sinnvolles finden können, ist es immer noch besser, eine leere Nachricht zu schreiben, als überhaupt nicht zu verpflichten, wenn Sie sollten.

Wenn Ihnen keine gute Commit-Nachricht einfällt, weil alles, was Sie sich einfallen lassen, dumm klingt, denken Sie daran, dass dies in Ordnung ist. Von Commit-Nachrichten wird erwartet, dass sie das Offensichtliche angeben, sodass sie für Sie beim Schreiben zwangsläufig dumm klingen. Aber glauben Sie mir, wenn Sie einen Monat später alte Revisionen überprüfen müssen, werden Sie selbst für die dummen Nachrichten über keine Nachrichten dankbar sein.

4
Mike Nakis

Übernehmen Sie jedes Mal, wenn Sie eine "logische" Änderung vornehmen. Wenn Sie beispielsweise eine neue Funktion implementieren, tun Sie dies Schritt für Schritt. Jeder dieser Schritte hängt normalerweise voneinander ab. Sie können diese Schritte also einfach separat festschreiben und in der Festschreibungsnachricht erklären, warum jeder Schritt erforderlich ist.

Die Commit-Nachricht ist wirklich wichtig. Sie müssen vermeiden zu sagen was Sie tun, sagen warum Sie tun es. Der Code dokumentiert die Änderungen bereits, aber in 6 Monaten werden Sie froh sein zu sehen, warum Sie sie vorgenommen haben.

Dies ist auch nützlich, wenn zufällig jemand einspringt und Sie nicht mehr allein sind. Selbst für Sie erleichtert ein sauberer Verlauf die Verwendung eines git blame, Um zu wissen, wann und warum diese Zeile mit einem Fehler geändert wurde.

Wenn Sie kleine Commits anstelle von großen Schlammballenänderungen vornehmen, können Sie auch den Zwischenzustand testen. Sie können die Änderungen speichern, wenn Sie dringend etwas freigeben müssen. Wenn Sie einen Fehler einführen, während er zuvor funktioniert hat, können Sie ihn speichern und prüfen, ob es Ihre nicht festgeschriebenen Änderungen sind, die den Fehler verursachen, oder ob dies in einem älteren Commit war.

Sie können auch die Kraft von git bissect Entfesseln, die Ihnen das Festschreiben dieses bösen Fehlers anzeigt. Wenn das Commit 2.000 Zeilen lang ist, hilft es immer noch, aber nicht so viel ...

Eine andere Sache ist, dass dies der erste Schritt für die kontinuierliche Integration (CI) und dann die kontinuierliche Bereitstellung (CD) ist. CI und Ihre Tests können bei einem neuen Commit ausgelöst werden, sodass Sie jedes Mal erfahren, wenn Sie Ihre Änderungen verschieben, ob sie etwas beschädigen oder nicht. Auf diese Weise können Sie feststellen, ob die Bereitstellung sicher ist oder nicht, und Sie werden darüber informiert, sobald das Problem auftritt, und nicht erst vor Ihrer Veröffentlichung, wenn Sie in Eile sind.

Zu Ihren anderen Fragen:

  • übernehmen Sie keine Dinge, die Sie nicht einmal kompiliert haben, es sei denn, Sie sind bereit, Ihren Verlauf dafür neu zu schreiben (mit git rebase --interactive).
  • eine einzeilige Änderung verdient ein Commit, wenn sie einen separaten Zweck hat (behebt einen Fehler oder steht in keinem Zusammenhang mit Ihren derzeit nicht festgeschriebenen Änderungen). Verwenden Sie git add --patch, Um diese zu inszenieren.
  • sie müssen sich nicht zwingen, sich vor dem Abendessen zu verpflichten, es sei denn, Sie haben wichtige Dinge, die Sie sich nicht leisten können, zu verlieren. In diesem Fall möchten Sie möglicherweise Ihre laufenden Arbeiten in einem separaten Zweig festschreiben.
  • das Festschreiben und Verschieben in ein Remote-Repository ist eine Sicherung. Wenn Sie nur einmal pro Woche ein Commit durchführen und pushen, können Sie im schlimmsten Fall eine Woche Arbeit verlieren.
1
liberforce

Ich bin ein gewöhnlicher Committer und habe festgestellt, dass das zu mir passt, aber zugegebenermaßen sind meine Commit-Nachrichten fast immer wie folgt:

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Daher kann ich nicht genau sagen, dass das Ausführen so häufiger und gewohnheitsmäßiger Festschreibungen in meinem Zweig (Mercurial) genau die detailliertesten Festschreibungsprotokolle gefördert hat. Manchmal schreibe ich sogar den Code zur Hälfte fertig, wenn meine Frau mich zum Beispiel zum Abendessen auffordert. Dann kopiere ich nur hastig die vorherige Commit-Nachricht "Arbeiten an [...]" und verwende sie.

Meine Commit-Protokollmuster lauten normalerweise wie folgt: "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

Auf der anderen Seite hat es meinen Hintern gerettet. Manchmal stoße ich auf einen Edge-Fall, den ich nicht erwartet und getestet habe. An diesem Punkt helfen mir die häufigen Commits, genau herauszufinden, wo ich den Fehler eingeführt habe.

Ich weiß also nicht, was die besten Gewohnheiten sind, und ich bin sicherlich nicht derjenige, der sich die idealen Commit-Protokollierungsgewohnheiten anhört, aber ich kann mit Sicherheit sagen, dass ein häufigeres Commit definitiv hilfreich sein kann, wenn Sie eine Regression durchführen müssen.

Sollte jede einzeilige Änderung ein Commit erhalten?

Ich habe zuvor einzeilige Änderungen vorgenommen, aber normalerweise knifflige, und vielleicht hatte ich wenig Zeit. Meine Verpflichtungen ähneln nicht immer perfekten und vollständigen Arbeits- oder Veränderungseinheiten. Wie gesagt, manchmal sind sie nur das Ergebnis meiner Frau, die mich gebeten hat, unerwartet zum Abendessen auszugehen.

TBH Viele meiner Commits, die diesem "Working on [...]" - Protokollmuster folgen, modellieren keine kohärenten Änderungseinheiten (warum ich oft keine bessere Nachricht als "Working on [...]" Finden kann), sondern nur das Ergebnis meiner Aufnahme eine Verschnaufpause, als würde ich mir eine Tasse Kaffee machen. Die Nachricht "Completed [...]" Zeigt das Ende dieser Arbeitseinheit an, und dort schreibe ich oft eine viel detailliertere Nachricht zusammen mit den ersten Nachrichten vom Typ "Started working on [...]", Wenn ich gerade anfange, an etwas zu arbeiten. Wenn Sie durchschnittlich alle 15 Minuten festschreiben, sind diese "Arbeiten an [...]" Nachrichten eher wie Zwischenmeldungen für das, was jemand in einem umfangreicheren Festschreiben mit einer detaillierteren Nachricht festschreiben könnte.

Sollte ich mich vor einem Test festlegen (z. B. zumindest für Syntax-/Kompilierungsfehler und muss ihn dann vollständig rückgängig machen; da die Idee nicht funktioniert hat oder die Nachricht eine Lüge ist)?

Ich mache es einfach, bevor ich manchmal Tests durchführe (wieder, wenn ich ein unerwartetes Ereignis hatte). Auch wenn ich alleine bin, mache ich Push auf einen Server (nur einer läuft hier zu Hause in einem LAN), der CI macht. Das mag übertrieben erscheinen, aber keine Ahnung, ich habe mich an meinen früheren Arbeitsplätzen so daran gewöhnt. Außerdem möchte ich nicht die Mühe haben, jedes Mal alle meine Geräte- und Integrationstests von Hand ausführen zu müssen. Ich mag es, wenn das alles nur mit dem Schieben verbunden ist. Wenn ein Test fehlschlägt, ist es einfach genug, vorwärts zu arbeiten, wo ich die Regression durchführe, den Fehler in der letzten Version korrigiere und weitermache. Das heißt, ich mache mindestens build den Code gegen einen Debug-Build, bevor ich festschreibe.

Sollte ich sicherstellen, dass ich mich jeden Morgen/Nachmittag verpflichte, bevor ich aufhöre, zum Abendessen zu arbeiten, solange es noch frisch ist?

Ich mag es, mich zu verpflichten, bevor ich ausgehe und eine Pause zwischen dem Programmieren mache. Ich habe nicht wirklich darüber nachgedacht, warum genau, bis ich auf diese Frage stieß. Ich nehme an, es soll verhindern, dass ich dort weitermache, wo ich aufgehört habe, ohne dort ein Commit-Protokoll zu erstellen, anstatt dort, wo ich aufgehört habe, dass ich mich unterscheiden kann und so weiter. Hmm, ich muss darauf zurückkommen, da es theoretisch vielleicht nicht benötigt wird, wenn man bedenkt, wie oft ich mich verpflichte. Ich fühle mich immer noch wohler, wenn ich mich verpflichte und drücke, bevor ich den Computer aus irgendeinem Grund verlasse. Ein Teil davon könnte die frühere psychologische Angst sein, dass beispielsweise der Computer nach meiner Abreise in Brand gerät und Projektmanager in den Tagen, als wir SVN mit den Entwicklern verwendeten, manchmal wochenlang ohne Verpflichtungen waren, die uns den Hals runteratmen und ständig daran erinnern Wir müssen den Code so oft wie möglich einchecken und uns daran erinnern, dass unser Code Eigentum des Unternehmens ist. Außerdem ist es ein bisschen effizienter, insbesondere beim Pushing, damit mein CI-Prozess alle Tests ausführen kann, während ich nicht da bin, damit ich zurückkommen und die Ergebnisse sehen kann.

Oh, und manchmal betrinke ich mich ein bisschen, nachdem ich gegangen bin, und es ist normalerweise eine schlechte Idee, zu versuchen, komplexen Code zu schreiben, während ich betrunken bin (wenn auch nicht immer; einmal habe ich mir ein wirklich nettes Kontextmenüsystem ausgedacht, nachdem ich einen Eureka-Moment im betrunkenen Zustand hatte. aber ich hatte nur 6 Biere und es war nicht so komplex zu codieren). Wenn ich das versuche, habe ich zumindest den nüchtern geschriebenen Code festgeschrieben, bevor ich gegangen bin, um zurückzukehren, anstatt den betrunkenen Code mit dem nüchternen Code zu mischen. Zu diesem Zeitpunkt könnte mein Festschreibungsprotokoll wie folgt lauten: "Reverting back to code written before Jagermeister shots." Ich mache das nicht sehr oft, es sei denn, ich habe mich von betrunkenem Code inspirieren lassen, aber in diesen seltenen Fällen hat es wirklich geholfen, dass ich etwas begangen habe, bevor ich ausgegangen bin und mich betrunken habe.

0
user204677

Wie oft sollte ich mich verpflichten?

Als Solo-Entwickler verpflichte ich mich im Allgemeinen immer dann, wenn ich das Gefühl habe, nach grundlegenden Tests eine wesentliche Änderung vorgenommen zu haben, und wenn ich am Ende der Nacht ein Projekt verlasse.

Sollte jede einzeilige Änderung ein Commit erhalten?

Nein, es sei denn, diese einzeilige Änderung wird eine Funktion oder einen Fehler erheblich verändern.

Sollte ich mich vor einem Test festlegen (z. B. zumindest für Syntax-/Kompilierungsfehler und muss ihn dann vollständig rückgängig machen; da die Idee nicht funktioniert hat oder die Nachricht eine Lüge ist)?

Wahrscheinlich nicht. Zumindest für mich mache ich den größten Teil meiner Tests und Codierungen auf einer "Arbeitskopie" und verpflichte mich, nachdem ich mit meinen Änderungen zufrieden bin. In vielen IDEs wird mir gezeigt, was sich geändert hat, bevor ich das Commit tatsächlich durchführe, und es wird mir die Möglichkeit gegeben, dem Commit Notizen beizufügen

Sollte ich sicherstellen, dass ich mich jeden Morgen/Nachmittag verpflichte, bevor ich aufhöre, zum Abendessen zu arbeiten, solange es noch frisch ist? Was verpasse ich durch schlechte VCS-Gewohnheiten?

Ich bin nicht sehr vertraut mit VCS oder welchen schlechten Gewohnheiten es verursacht. Ich glaube, ich habe meine Meinung dazu größtenteils als Antwort auf die erste Frage geteilt.

Als Antwort auf die postulierte allgemeine Frage scheinen Sie hauptsächlich Commits als Zweige zu verwenden, die in einem anderen Antwortbeitrag behandelt werden. Ich bin mir nicht sicher, welches IDE Sie verwenden, das eine gute Rückgängig-Historie usw. hat, aber ich habe keine gefunden, die ich nach dem Neustart des IDE und dem Einzug für gut hielt zwischen Maschinen.

0
dbuell