Hallo,
autsch. Danke, sollte man wissen. Ich habe mich gefragt wofür man diese neuen cmdlets wirklich braucht... also jetzt mal im tatsächlichen, täglichen Einsatz. Für die Aktualisierung einer Standarddatenbank braucht man es anscheinend nicht
, und praktisch alle Kundendatenbanken haben AddOn-Objekte. Da hat man dann schon mal Glück wenn man die alle als Text exportieren kann... also wenn man nicht die Microsoft W1-ich-darf-alles Lizenz hat, sondern eine normale Partnerlizenz. Das kann man ggf. noch umschiffen. Irgendwie bekommt man die wichtigen Objekte als .txt raus. Dann möchte ich ein AddOn (was ja auch auf einer Basisversion lebt) auf eine neuere Version heben oder in eine Kundendatenbank einmergen. Oder nur ein Update davon, z.B. OPPlus 7.05 (derzeit 7.03.04 in der Kundendatenbank drin). Mal abgesehen davon, dass auch die Updates wieder auf einer anderen Basisversion als meine Kundendatenbank ist oder sein kann (mit den RollUps/Cumulative Updates ist die Wahrscheinlichkeit nahe 1), muss ich meine Mergeaktionen so aufteilen, dass ich immer aus 3 Basisdateien eine vierte erzeuge, dann die Konflikte auflösen, mit einem Mergeprogramm meiner Wahl, das Ergebnis in eine NAV-Datenbank einlesen, schauen ob die Syntax korrekt ist, wieder auslesen, weiter gehts, bis ich die Objekte in der Kundendatenbank habe. Das ist so ähnlich (ich würde sagen nicht ganz so effektiv) wie ich bis Anfang 2013 mit Subversion (TortoiseSVN), NavObjectSplitter (danke, Carsten :), einigen cmd-Dateien und FreeCommander gearbeitet habe und auf Arbeit immer noch mache. Nur das der Merge sowieso von Subversion bereitgestellt wird. Die kennen keine NAV Objektsyntax, das ist aber auch alles. Die Problematik mit den Control IDs, Versionsstrings, Kommentarsektionen und Sprachschichten hat man da gefühlt ertmal genauso wie mit den cmdlets. Als ich das Whitepaper zu den cmdlets gelesen habe dachte ich mir: Ja iss schon cool wenn die die Syntax kennen und das richtig herum zusammenbauen. Aber wirklich Konflikte lösen geht damit auch nicht, und der Merge macht immer nur einen 3seiten-Merge, die ganze Changeset-Historie haben sie ja nicht. Da muss man dann wie bisher ran.
Deutlich effektiver wirds mit sowas wie Mercurial als Versionskontrollsystem, ist zumindest meine Erfahrung. Ringsrum ists praktisch das gleiche, aber die Mergefunktion kann zwischen verschiedenen Zweigen hin und her mergen... und das mit keinen größeren Problemen als oben beschrieben, das aber ohne die bei SVN nötigen Zwischenversionen. Händische Nacharbeit ist leider immer erforderlich. Und das man die Syntax halt kennt.
Was toll wäre: ein TortoiseMerge (oder meinetwegen ein kdiff3) was die NAV-Syntax kann. Und zusätzlich eine Funktion die das ersetzen von Versionskürzeln in den Versionsstrings regelt, mit Datumsregel, und noch ein paar andere Kleinigkeiten. Und ein Textdatei-Syntaxchecker. Das würde gut weiterhelfen :)
LG Jens