Diskussion zum Artikel "Umstellung auf MQL5 Algo Forge (Teil 2): Arbeiten mit mehreren Repositorys" - Seite 2
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich schlage vor, dass Sie während des Verbesserungsprozesses versuchen, ein paar Iterationen einer primitiven Verzweigungsstrategie durchzuführen, indem Sie nur MetaEditor und die Weboberfläche verwenden.
Punkt 3 ist derzeit ohne die Verwendung externer Tools nicht möglich. Die Tatsache, dass Punkt 2 über die Website durchgeführt werden kann, macht es also nicht einfacher, weil es eine Sackgasse ist.
Ich habe in dieser Diskussion nichts Neues gesagt - ich habe bereits vor ein paar Monaten über all dies berichtet. Jetzt gibt es einen Artikel, in dem die Punkte 1 und 2 beschrieben werden, aber irgendwie ist es so, dass Punkt 3 nicht in dem Artikel steht (obwohl Punkt 3 eine logische Fortsetzung ist).
Punkt 3 fehlt, weil ich den Ansatz bevorzuge, bei dem die Zweige verschiedener Merkmale unterschiedliche Namen haben, nicht immer den gleichen (nächsten). Bei Ihrem Ansatz ist mir nicht klar, warum next überhaupt entfernt werden sollte? Er scheint eine ähnliche Bedeutung zu haben wie der Entwicklungszweig im Haupt-/Entwicklungsbündel und wird verwendet, um an jeder neuen Funktion zu arbeiten, wenn Funktionen nacheinander hinzugefügt werden.
Nach ein paar Tagen Brainstorming habe ich einen Weg gefunden, zumindest die Liste der "defekten" Dateien zu ergänzen.
Ja, ich habe auch einmal ein Skript ausprobiert, um alle kompilierten Dateien aus dem gemeinsamen Repository zu löschen, was sich aber schnell als unnötig herausstellte. Da ich die Weboberfläche nicht benutzte, um mit Dateidifferenzen umzugehen, war es mir egal, dass sie den Inhalt dort nicht anzeigten. Es ist also möglich, die Liste der "defekten" Dateien herauszufinden, aber warum? Wenn bereits bekannt ist, dass es sich um alle Dateien handelt, die von ME erstellt wurden (UTF-16 LE kodiert), dann sind das alle meine Repository-Dateien mit Ausnahme von README.md, .gitignore und ein paar anderen.
Renat, können Sie mir sagen, ob es sinnvoll ist, alle Quellen auf UTF-8 zu konvertieren oder wird ME weiterhin nur auf UTF-16 LE ausgerichtet sein? Ich glaube, irgendwo in den Zweigen der neuen Builds oder irgendwo anders wurde es über den Übergang zu UTF-8 erwähnt, aber vielleicht schien es?
Oh, ich habe gerade eine neue Datei in ME erstellt (Neue Klasse), also wurde sie sofort in UTF-8 erstellt.
Bei Ihrem Ansatz ist mir nicht klar, warum Sie den nächsten Zweig überhaupt löschen sollten?
Ich lösche einen Zweig immer sofort, nachdem er vollständig mit einem Zweig einer höheren Stabilitätsstufe zusammengeführt wurde. Das ist eine Gewohnheit und ich bin sicher, dass es eine sehr nützliche Gewohnheit ist.
Aus rein technischer Sicht macht das Wiederherstellen eines Zweigs oft einen spürbaren Unterschied in Form eines Parent-Commits (übergeordneter Commit des nächsten Commits). Manchmal ist das nicht kritisch und wirkt sich nur auf die Nutzbarkeit des Commit-Graphen aus, und manchmal kann man nicht auf die Neuerstellung verzichten.
[Bearbeiten]
Im Allgemeinen finde ich es seltsam zu argumentieren, dass es notwendig ist, Zweige aus dem lokalen Repository entfernen zu können. In Anbetracht der Tatsache, dass das Verzweigungsmodell von Git sein Killer-Feature ist und Git das häufige Erstellen, Löschen und Zusammenführen von Zweigen fördert.
Da ich die Weboberfläche nicht benutzte, um mit Dateidifferenzen umzugehen, machte es mir nichts aus, dass sie den Inhalt dort nicht anzeigten.
Ich benutze die Weboberfläche auch nur sehr selten. Und ich verwende keine Git-Schaltflächen in MetaEditor. Ich schaue in Git Bash für Windows nach - direkt im Terminal - das ist für mich ausreichend und bequem.
Man kann also die Liste der "defekten" Dateien herausfinden, aber warum?
Um die Liste der defekten Dateien zu kennen, damit man sie reparieren kann. Um sie zu reparieren, damit man sich diff ansehen kann.
Wozu ist diff da? [löschte einen unwichtigen Satz, der dem automatischen Übersetzer Probleme bereitete].
Wenn bereits bekannt ist, dass es sich um Dateien handelt, die von ME erstellt wurden (in UTF-16 LE-Kodierung)
Ich habe dies vor ein paar Monaten getestet. Der Assistent erstellt UTF-8 (normale, nicht kaputte Dateien). Auch der MT4-Assistent erstellt normale Dateien. Während dieser Tests ist es mir nicht ein einziges Mal gelungen, eine "defekte" Datei vom Assistenten zu erhalten.
Manchmal prüfe ich Dateien mit diesem Skript, bevor ich sie übertrage. Und, wie sich herausstellte, nicht umsonst - es gab Fälle, in denen normale Dateien plötzlich die Kodierung änderten. Vielleicht nach dem Einfügen von etwas aus der Zwischenablage, ich weiß es nicht genau. Es ist unwahrscheinlich, dass Kyrillisch dabei war - ich habe es schon vor langer Zeit aufgegeben, es auch in Kommentaren zu verwenden.
Das kyrillische Alphabet war kaum vorhanden - ich habe es schon vor langer Zeit aufgegeben, es auch in Kommentaren zu verwenden.
Offenbar habe ich mich geirrt. Ich habe dies gerade der .mq5-Datei mit UTF-8-Kodierung hinzugefügt:
// Kyrillischund nach dem Speichern der Datei änderte sich die Kodierung in "UTF-16 LE BOM".
Es scheint der Fehler von MetaEditor zu sein. Ich habe kyrillische Zeichen hinzugefügt und die Datei mit Notepad++ gespeichert, und die Kodierung blieb UTF-8.
Ich finde es auch seltsam, für die Notwendigkeit zu argumentieren, Zweige aus dem lokalen Repository entfernen zu können. Wenn man bedenkt, dass das Verzweigungsmodell von Git seine Killerfunktion ist und Git das häufige Erstellen, Löschen und Zusammenführen von Zweigen fördert.
Daher bin ich auch dafür, Zweige zu löschen, nachdem sie mit den Hauptzweigen zusammengeführt wurden. Es ist nur das erste Mal, dass ich höre, dass nach dem Löschen ein Zweig für die neue Fiche mit dem gleichen Namen erstellt wird, und nicht ein neuer Zweig.
Was ist der Zweck von diff?
Ja, es ist eine sehr notwendige Sache. Ich benutze es auch aktiv, aber nur in VS Code. Und dort gibt es seltsamerweise keine Abstürze, obwohl ich Dateien mit "schlechter" Kodierung durchsehe.
So etwas ist mir noch nie begegnet. Es ist auch ziemlich unerwartet. Vielleicht war der Bruch normaler Dateien auf die gleichzeitige Verwendung verschiedener ME-Builds zurückzuführen, um mit denselben Dateien zu arbeiten? Ich weiß es nicht...
Ich habe mir die Commit-Historie angesehen und festgestellt, dass Dateien, die vor zwei Monaten hinzugefügt wurden, tatsächlich bereits UTF-8 kodiert sind, während Dateien, die vor drei Monaten hinzugefügt wurden, immer noch UTF-16 LE sind. Anscheinend wurde die Kodierung irgendwann in dieser Zeit auf UTF-8 umgestellt.
Ich schätze, ich habe mich geirrt. Ich habe dies gerade der .mq5-Datei mit UTF-8-Kodierung hinzugefügt:
und nach dem Speichern der Datei wurde die Kodierung auf "UTF-16 LE BOM" geändert.
Es scheint der Fehler von MetaEditor zu sein. Ich habe kyrillische Zeichen hinzugefügt und die Datei mit Notepad++ gespeichert, und die Kodierung blieb UTF-8.
Ich bestätige, dass nach dem Hinzufügen der russischen Buchstaben und dem Speichern der Datei die Kodierung von UTF-8 zu UTF-16 LE wechselt. Wenn alle russischen Buchstaben entfernt und gespeichert werden, bleibt es bei UTF-16 LE.
Es scheint der Fehler von MetaEditor zu sein.
Hier ist ein Beweis, dass man UTF-8, Kyrillisch und Git kompatibel machen kann:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
Alles, was Sie tun müssen, ist MetaEditor zu bitten, die Dateikodierung nicht zu ändern.