Warum werden nicht einfach tokens versioniert?
-
Wenn ich mich recht erinner bekommt BeyondCompare das ganz gut hin, solche unterschiede kann man dann als "unimportand differences" ausblenden
ExamDiff weiss ich grad nicht.
Aber der Vorteil der versionierungssystemen ist ja das es sprach unabhängig ist.
Ich denke da an F#, da sind die 4 Leerzeichen sehr wichtig, zuviele oder zu wenige können Code zerstören.
Wie will man das in token einbauen, und selbst dann, brauchste n "TokenBuilder" für jede Sprache.
-
Ja, das ist mir klar, dass man extra Lexer für jede Sprache braucht. Aber man kann ja auch als Fallback immer noch die üblichen Diff-Tools verwenden.
-
otze schrieb:
Bei Python gäbe das sicherlich Probleme. Außerdem muss dann das Versionierungstool nicht mehr nur Versionierung, sondern auch Tokenizing für unterschiedliche Sprachen machen...
Bei Python ist das zeilenbasierte diffen halt schon zufällig ideal. Für C++ ist es das nicht. Darauf möchte ich hinaus.
-
Das ist doch kein Problem der Versionskontrolle. Das ist nur ein Problem des Differs. Mit LLVM könnte etwas ähnliches wie Deine Idee durchaus auch per Differ bequemer machbar werden als bis dato.
Der Differ ist bei den mir bekannten VCS mehr oder wenig beliebig konfigurierbar. Dh. mit Git oä. könntest Du auch heute schon einfach so einen fortschrittlichen Differ verwenden, sofern es den bereits gäbe.
-
Gibt es denn Gründe, warum sich sowas scheinbar nicht durchsetzt? Ist es nur, weil es für jede Sprache spezifisch gemacht werden muss?
-
Es ist ziemlich nontrivial, einen Differ zu schreiben, der so viel über die Sprache weiß. Wie gesagt, mit LLVM dürfte das deutlich leichter werden für C++.
Die Frage ist trotzdem, wieviel man davon als Entwickler überhaupt profitiert. Ich empfinde Unified-Diffs als sehr lesbar, ich persönlich würde gar nichts anderes verwenden wollen. Spezialisierte Differ sind prinzipiell für viele Anwendungszwecke natürlich eine gute Sache, aber solange man als Entwickler noch Sourcecode bearbeitet, möchte ich auch die von Dir angeführten Änderungen in Patches noch sehen können.
Mein Hirn ist außerdem ziemlich gut dabei, derartige Änderungen als solche kosmetischer Natur zu erkennen und ggf. auszublenden.
Aber wie gesagt, wenn überhaupt, ist das alles nur Darstellungssache. Dem VCS sind all diese Dinge egal, das sollte nichts von der Sprache des Codes wissen müssen, sondern einfach nur frischfröhlich Zustände bzw. Änderungen tracken müssen.
-
Optimizer schrieb:
Ein Diff kann unnötig umständlich aussehen:
- if( something ) { + if( something ) + { // mach was }so sollte ein Diff nie aussehen! Entweder man einigt sich auf eine Formatierung oder man hält sich an die Konventionen der jeweiligen Datei.
(beides leider schwierig)
Formatierung muss theoretisch überhaupt nicht eingecheckt werden, sondern kann beim auschecken von der IDE je nach Präferenz dargestellt werden.
"theoretisch" ... ich kenne leider kein tool was das für C++ wirklich schafft.
Ich denke aber auch, dass es auf lange Sicht sinnvoll sein kann, den source code formatfrei abzuspeichern.
wenn schon denn schon. Aber bis dahin einfach die Klammern richtig setzen
-
Was ist mit Stellen, an denen man von seiner Standardformatierung abweicht?
funktion(mitGanzVielenParametern, dieSoVielPlatzBenoetigen, dassManSchonmal, neNeueZeileAnfaengt, undDannBuendig, mitDemAnfangDerParameterliste, weiterschreibt);
-
Achtung, Formatierungsflamewar voraus.
Michael E. schrieb:
Was ist mit Stellen, an denen man von seiner Standardformatierung abweicht?
funktion(mitGanzVielenParametern, dieSoVielPlatzBenoetigen, dassManSchonmal, neNeueZeileAnfaengt, undDannBuendig, mitDemAnfangDerParameterliste, weiterschreibt);Igitt, sowas würde ich nie machen. (Aka: Habe ich vor ein paar Jahren selbst gemacht, würde ich jetzt nicht mehr machen.)
Was machst Du, wenn da zwischen "dassManSchonmal" und "neNeueZeileAnfaengt" ein neuer Parameter reinsoll? Manuell alles neu ausrichten?
Alle Parameter in eine Zeile oder einen Parameter pro Zeile. Alles andere ist furchtbar, nicht nur wegen der katastrophalen Diffs.
Die Zeilenumbrüche kosten mich ja nichts, da dürfen ruhig ein paar mehr rein.
Und wenn man es mit solchen furchtbaren Funktionen zu tun hat, die siebzehn Parameter entgegennehmen, ist auch die Wahrscheinlichkeit höher, dass man da einige Male "0" oder "NULL" oder irgendwas nonintuitives stehen hat, was man mit einer Zeile pro Parameter auch viel besser inline kommentieren kann.
-
Solche Methoden könnte man mit einem "*Args" Parameter Objekt Herr werden.
Ich versuch mich immer an die 3er Regel zu halten ("Versuche nie mehr als 3 Parameter zu haben"), ich mach natürlich auch ausnahmen, aber bei solch einer Menge lager ich das in einem *Args Objekt aus.
-
nman schrieb:
Igitt, sowas würde ich nie machen. (Aka: Habe ich vor ein paar Jahren selbst gemacht, würde ich jetzt nicht mehr machen.)
Ich machs auch nicht. Aber es gibt Leute, die es machen, aber nur manchmal, wenn die Zeile gefühlt zu lang wird.
-
Michael E. schrieb:
Ich machs auch nicht. Aber es gibt Leute, die es machen, aber nur manchmal, wenn die Zeile gefühlt zu lang wird.
Ich habe noch alten Code von mir, in dem ich sowas mache, herumliegen. Praktischerweise sind die Diffs da sehr lesbar, wenn ich sowas ausbessere.
Mache ich typischerweise aber eher nicht, wenn ich den Code nicht ohnehin angreifen würde.
-
DrGreenthumb schrieb:
Optimizer schrieb:
Ein Diff kann unnötig umständlich aussehen:
- if( something ) { + if( something ) + { // mach was }so sollte ein Diff nie aussehen! Entweder man einigt sich auf eine Formatierung oder man hält sich an die Konventionen der jeweiligen Datei.
(beides leider schwierig)
Formatierung muss theoretisch überhaupt nicht eingecheckt werden, sondern kann beim auschecken von der IDE je nach Präferenz dargestellt werden.
"theoretisch" ... ich kenne leider kein tool was das für C++ wirklich schafft.
Ich denke aber auch, dass es auf lange Sicht sinnvoll sein kann, den source code formatfrei abzuspeichern.
wenn schon denn schon. Aber bis dahin einfach die Klammern richtig setzen
Was du beschreibst (Klammern "richtig" setzen) ist offenkundig ein Workaround, und zwar genau von der Sorte wie ich ihn gern überflüssig machen möchte. Darauf kann die Antwort nicht sein "mach doch diesen Workaround".
-
Wie auch schon gesagt wurde: Was Du möchtest kann keine IDE da draußen vernünftig. Warum sollen Versionskontrollsysteme schlauer sein?
Wie gesagt, warte mal ab, was sich mit LLVM so tut, vielleicht tut sich da dann was. Wird aber trotzdem nix an den Versionskontrollsystemen ändern, sondern nur an den Differn, die man ja praktischerweise überall einfach austauschen kann.
-
Ich verstehe nicht inwieweit LLVM da reinspielt.
Lexer gibt es doch wie Sand am Meer, dazu braucht man kein LLVM Projekt.@Topic: ich würde das ebenfalls *niemals* im VCS machen, sondern nur im Diff-Viewer. Maximal dass man dem VCS beibringt Flags/Tags zu den Revisionen dazuzuspeichern, damit man im "Log" schnell sehen kann ob eine Revision ausschliesslich aus "unwichtigen" Änderungen besteht.
----
DrGreenthumb schrieb:
Optimizer schrieb:
Ein Diff kann unnötig umständlich aussehen:
- if( something ) { + if( something ) + { // mach was }so sollte ein Diff nie aussehen! Entweder man einigt sich auf eine Formatierung oder man hält sich an die Konventionen der jeweiligen Datei.
(beides leider schwierig)
Also ich finde nicht nur eine Datei, sondern ein ganzes Projekt sollte einheitlich formatiert sein. Und das führt dazu dass man unweigerlich irgendwann mal aufräumen muss. Idealerweise macht man dann Commits die nichts ausser Reformatierung enthalten. Ohne Tools zu checken ob sich auch wirklich nichts wichtiges geändert hat, ist dann aber nahezu unmöglich, da meistens das ganze File "rot" ist (mein Diff-Viewer, malt rote Linien neben den Scrollbalken überall wo sich im File was geändert hat).
Von daher fände ich besseren Support im Diff-Viewer schon wünschenswert.
p.S.: da bald Weihnachten ist: ich wünsche mir einen Diff-Viewer der Renames erkennt und entsprechend als "unwichtig" ausblenden kann
-
hustbaer schrieb:
Ich verstehe nicht inwieweit LLVM da reinspielt.
Lexer gibt es doch wie Sand am Meer, dazu braucht man kein LLVM Projekt.Für primitivere Formatierungsgeschichten braucht man auch kein LLVM. Aber für die von Dir genannten Renames oä. wäre das sehr nett. Zb. "Variable Foo::x wurde zu Foo::y" umbenannt statt viele Diffs. Damit lassen sich viele Sachen highleveliger zusammenfassen, als sie im Code stehen.
Nein, das hat natürlich nicht viel mit dem Vorschlag von Optimizer zu tun. Aber es könnte ohne weiteres die Killeranwendung sein, die dann natürlich seine Ideen mitimplementiert.
Wobei ich gestehen muss, dass ich nicht viel Ahnung habe, was es da draußen an Differn gibt, ich verwende immer noch ediff und vermisse selten irgendetwas ernsthaft.
