Standard-GIT mit Twincat 3.1-Projekten nutzen

[Jochen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

folgendes Problem:

Beckhoff supportet für Twincat3 eine sourcekontrolle, die (so ist es von Seiten Beckhoff angedacht) die VisualStudio Kaufversion von Microsoft erfordert.
Wir setzen Twincat3 nur mit der VS Shell ein und nutzen Standard Git für die Versionskontrolle.

Dies stößt an die Grenzen, sobald es Mergekonflikte in der *plcproj Datei gibt.

Nun möchte ich das Beckhoff Project Compare Tool dergestalt nutzen, dass Git es als Standard Mergetool verwendet.

Git stellt hier ja die bekannten Schalter: $BASE, $LOCAL, $REMOTE und $MERGE bereit.

Nach https://infosys.beckhoff.com/englis...3/tc3_sourcecontrol/9007200497212427.html&id=
wird das Beckhoff comparetool als Mergewerkzeug für beliebige clients wie folgt aufgerufen:

Merge:


C:\TwinCAT\3.1\Components\TcProjectCompare\TcProjectCompare.exe /dl "destinationsymbolic" /dr “sourcesymbolic" <destinationfile> <sourcefile> <output> /sc



Example (PlasticsSCM): C:\TwinCAT\3.1\Components\TcProjectCompare\TcProjectCompare.exe /dl "@destinationsymbolic" /dr "@sourcesymbolic" "@destinationfile" "@sourcefile" "@output" /sc

Ich bekomme es nun nicht hin, diese Anforderungen korrekt mit den Git-Schaltern zu versorgen.
Der Beckhoff Support stellt sich quer und sagt: "Beckhoff unterstützt hier halt nur PlasticSCM......."

Kann mir jemand hier helfen?

Danke im Voraus

Gruß

Jochen

 

[KGU]

Beckhoff supportet für Twincat3 eine sourcekontrolle, die (so ist es von Seiten Beckhoff angedacht) die VisualStudio Kaufversion von Microsoft erfordert.

FALSCH! das ist nicht so von Beckhoff angebdacht. Wenn man kein volles VS hat, wird halt nur die Standardshell installiert! Mann muss sich dann den Source-Comtrol-Client seiner Wahl selber installieren. Wenn man etwas anderes nutzen möchte als TFS bzw. die Mircosoft GIT integration muss man dies ohnehin auch im vollen VS tun. Für die Shell könnte man sich somit den Team Foundation Explorer runterladen und installieren und sofort hätte man die Microsoft GIT Client zur Verfügung.
http://lmgtfy.com/?q=team+foundation+explorer

Git stellt hier ja die bekannten Schalter: $BASE, $LOCAL, $REMOTE und $MERGE bereit.

ist nicht allzu schwer die "bekannten" Schalter auf die vom Compare-Tool zu mappen, wenn man sich die jeweilige Bedeutung mal ansieht..

z.B. so:
[diff]
tool = tccompare
[difftool "tccompare"]
cmd = c:\\TwinCAT\\3.1\\Components\\TcProjectCompare\\TcProjectCompare.exe "$LOCAL" "$REMOTE" /sc

keepbackup = false
trustexistcode = true


[merge]
tool = tccompare
[mergetool "tccompare"]
cmd = c:\\TwinCAT\\3.1\\Components\\TcProjectCompare\\TcProjectCompare.exe "$LOCAL" "$REMOTE" "$MERGED" /sc


jetzt musst du nur noch in der gitattributes einstellen, für welche Dateiendungen das TcCompare-Tool aufgerufen werden soll.

"Beckhoff unterstützt hier halt nur PlasticSCM......."

diese Aussage kann ich mir fast nicht vorstellen, zudem ist sie falsch. Mit dem Compare Tool, welches mit der Version 3.1 Build 4020 voraussichtlich im Februar 2016 zum Download bereit stehen wird, kann man übrigens die Konfiguration für GIT direkt aus dem Compare-Tool heraus generieren.

 

[R.List]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

Ich habe ein Problem was ganz gut in diesen Thread passt, hoffe ich, also bitte nicht Schlagen .

Wir möchten gerne die Atlassian Tool Bitbucket(Git) einsetzen. Um dies auch "richtig" zu nutzen und die Qualität unserer Software zu steigern. Wollen wir nun mit Pull Requests arbeiten.

Nun zur eigentlichen Frage:

Wie bekomme ich da TcCompareTool dazu eine Local ausgecheckten branch (pull request branch) gegen den dev branch zu vergleichen?

Hoffe Ihr könnt mir weiterhelfen den auf der Hotline ist mal wieder keiner zu erreichen und wenn man jemanden bekom

 

[KGU]

Das Project compare Tool trägt sich auf Wunsch automatisch in die globale git config ein, oder in die der repositories. Ab da ist es GIT Funktionalität und hat nix mehr mit dem Compare-Tool zu tun.

Ein pull besteht bei git aus einem fetch und einem merge. Bei fetch wird noch nix herunter geladen und man bekommt nur eine "Liste" der Dateien die sich geändert haben. Danach erfolgt der Merge und wenn ein Konflikt besteht wird (sofern so konfiguriert) das TwinCAT Compare Tool aufgerufen. Das man einfach nur mit einer Version auf dem Server vergleicht ist bei git so nicht vorgesehen. Man kann höchstens den dev in ein Separates Verzeichnis ziehen und dann quasi die beiden Repositories/ Verzeichnisse vergleichen. Ich bin aber kein absoluter GIt Profi und lasse mich gern eines besseren belehren.

 

[R.List]

Hi,

Ich glaube ich habe nicht genau genug erklärt was wir machen wollen.

aber als erstes danke an KGU die lösung mit dem zweiten lokalen repo funktioniert will ich aber gerade vermeiden da ich glaube das das TcCompareTool das kann da es bei einem merge conflict ja auch zwei unterschiedliche brances beherrscht.

Was wollen wir also in Ausführlicher form.

Wir wollen ein Quallitygate schaffen in dem mehrere Programmierer einem Pull Request zustimmen müssen bevor dieser branch in den Basis branch gemerged wird. Dazu ist es notwendig das die Prüfenden Programmierer einen Compare (diff) zwischen den beiden branches sich anschuen können.

Ich habe nun dem TcCompareTool bereits mitgeteilt das wir Git nutzen und auch im VS als diff und merge Tool eintragen lassen.

Wie kann ich mir nun einen diff anschauen? Ich kann nur den TcCompareTool öffnen und dann verlangt es zwei Pfad angaben

 

[KGU]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie gesagt, meines Erachtens geht das so mit git nicht. Bei TFS und anderen SCM ist ein Branch eine Kopie der Sourcen. Das ist bei GIT NICHT so. Du hast einen Entwicklungsstrang und wenn du einen Branch anlegst, dann wird quasi ein Pointer mit diesem Namen auf einem Commit hinterlegt. Du bleibst aber auch bei mehreren Branches immer im selben Repository/ Ordner auf der Festplatte. Du erhälst dann den Inhalt eines Branches in dem Du ein Checkout des Branches auf diesen Pointer macht, der dir den Inhalt in deinem Verzeichnis auf genau diesen Stand zurück setzt. Wenn du einen anderen Branch willst, checkst du diesen in genau das selbe Verzeichnis aus! Um mit dem TwinCAT Compare Tool oder genauer gesagt mit irgendeinem Compare Tool einen Vergleich durchzuführen, brauchst du zumindest eine lokale temporäre Kopie der beiden Stände. Die bekommst du mit GIT normalerweise nicht mit nur einem Repository. Aber wie gesagt, wenn es jemand besser weiß, ich bin kein GIT Profi...

 

[Steller]

Moin zusammen,
wir sind dabei Git als Softwareverwaltungssystem für TwinCAT 3 einzuführen.

Wir haben für als Standard Mergetool den TcCompareTool ausgewählt.

Bei Änderungen in der Hardwarekonfiguration wollen wir nun, dass bei Mergekonflikten in der *.tsproj-Datei nicht das TcCompareTool geöffnet wird, sondern das Visual Studio Compare Tool (VsDiffMerge) verwendet wird. Ein harter Wechsel ist uns möglich. Wir können in der .gitconfig Datei zwischen den beiden Tools wechseln.

Wir wollen aber, dass TcCompareTool standardmäßig ausgewählt ist und nur bei Dateien mit der Dateiendung .tsproj das VsDiffMerge verwendet wird.

Grob stellen wir uns das so vor, dass in der .gitattributes Datei dieser Ausnahmefall festgelegt ist und das Aufrufen der unterschiedlichen Tool automatisch geschieht.

Hat damit schon jemand Erfahrungen gesammelt wie das umgesetzt werden könnte? In der .gitattribut haben wir bereits folgendes eingetragen:

[FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]*.tsproj merge=vsdiffmerge
*.tsproj diff=vsdiffmerge

Ist da vielleicht noch der Wurm drinne? Oder wird das an was anderen liegen?
[/FONT]

 

[KGU]

Ich könnte es Euch sagen, aber das werde ich nicht, denn das was ihr da machen wollt ist ... nicht intelligent (sry). In dem Merge tool (auch wenn es vielleicht nicht so aus sieht) steckt einiges an Intelligenz drinnen. Z.B. das wenn man Datentypen mergt, beide "Eltern" als gehidet drinnen stehen. Mit anderen Worten TwinCAT kennt die Geschichte eines Datentyps und kann dadurch entscheiden wie es reagiert wenn der Datentyp für Verknüpfungen oder für persistente Daten verwendet wird. Ebenso werden nicht alle GUIDs zufällig generiert, sondern an einigen Stellen über über den Hash des Inhalts, so dass wenn auf zwei verschienden System das selbe gemacht wird, auch die selbe GUID entsteht. Ansonsten hat man ungleich mehr Konflikte etc. Tut mir Leid, aber man kann sich Probleme auch selber ins Haus holen.
Nebenbei gesagt, kann man auch im TwinCAT Compare Tool Teile in Xml-Ansicht mergen. In der aktuellen Version unterscheidet es auch zwischen formalen und inhaltlichen Änderungen, man kann die SPS-Ordner komplett ausblenden, ebenso wie gleiche Elemente und formale Änderungen und noch einiges mehr.