Source Code Control LVDiff - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +--- Thema: Source Code Control LVDiff (/Thread-Source-Code-Control-LVDiff) Seiten: 1 2 |
Source Code Control LVDiff - eg - 03.03.2006 17:41 Vielleicht sollen wir das von C++ nach LV umprogrammieren und EXE daraus machen? Gruss Source Code Control LVDiff - Oliver Listing - 03.03.2006 18:12 Hi eugen, Das geht nicht, es sei denn du sagst mir wie man eine, mit LabVIEW erstellten exe, Parameter übergibt... Aber ich bin schon soweit, das ich mit Sicherheit sagen kann, das es an den Leerzeichen in den Pfadangaben zu LabVIEW liegt: c:programmenational instrumentsLabVIEW 8.0LabVIEW.exe Desweiteren habe ich schon herausgefunden, das man mit der Funktion GetShortPathName den Pfand in die DOS-Kurzform konvertieren kann. Wenn ich den Pfad als Konstante der Funktion übergebe hat es auch schon geklappt. Nun versuche ich es noch über die Variable. Drück mal die Daumen. Gruß Oliver Source Code Control LVDiff - Oliver Listing - 03.03.2006 18:58 Hi eugen, probier die mal... Oliver Source Code Control LVDiff - eg - 06.03.2006 10:05 Danke Oliver, es läuft ohne Fehlermeldung. Gruss, Eugen Source Code Control LVDiff - Oliver Listing - 06.03.2006 10:57 Hi eugen, leider löscht LV immer noch das vom CVS-Server geladene alte VI vor dem Aufruf von lvdiff. :evil: Mal sehen, was NI dazu sagt... Gruß Oliver Source Code Control LVDiff - eg - 27.04.2006 14:09 Hi Oliver, ich hatte wegen Tortoise SVN probleme bei der Erstellung von EXEs. Der App. Builder hat den Fehler 8 (File Permission Error) gemeldet. Als ich SVN deinstalliert habe bekam ich diesen Fehler nicht mehr. Was sagst du dazu? Source Code Control LVDiff - Oliver Listing - 28.04.2006 09:06 Hi eugen, das Problem ist bei mir mit TortoiseCVS meineserachtens noch nicht aufgetreten. Und ich bin eigentlich sicher, das ich schon eine exe erzeugt habe, seitdem ich cvs benutze... :? Hast du denn die Builddateien und die exe mit in SVN eingecheckt?? Eigentlich ja nicht im Sinne des Erfinders... Arbeitest du mit strictly?? Gruß Oliver Source Code Control LVDiff - eg - 28.04.2006 09:21 Hallo Oliver, allerdings habe ich das EXE nicht in SVN eingesteckt (ist ja unsinnig). Was strictly oder optimistic locking angeht, habe ich keine Ahnung. Was meinst du damit? Ich habe es eigentlich so rausgefunden: ich hatte ja seit einiger Zeit Probleme mit dem App. Builder. Siehe Topic "Application Builder Error 8". So habe ich NI Support angerufen und alles erzählt. Habe ein kleines Mini-Projekt nur zu Debugzwecken gemacht und an NI geschickt. Die konnten aus diesem Projekt problemlos EXE erstellen. Dann liegt das Problem in meiner PC- Hard- oder Software. Dann habe ich es meinem Arbeitskollege erzählt und er hat vorgeschlagen erstmal das Tool "Filemon" zu benutzen, um zu sehen auf welche Dateien überhaupt bei der Erstellung von EXEs zugegriffen wird. Komischerweise konnte ich mit dem laufenden Tool meine Applikationen erstellen!!!??? Na gut, dann habe ich halt gesehen, dass bei der Erstellung nicht nur LV, sondern auch TSVN auf VIs u.s.w. zugreift, wobei ich nur meine Projekte mit SVN überwache. So habe ich dann TSVN deinstalöliert und siehe da: keine Probleme mehr. Gruss, Eugen Source Code Control LVDiff - Oliver Listing - 28.04.2006 10:13 eugen graf schrieb:Was strictly oder optimistic locking angeht, habe ich keine Ahnung. Was meinst du damit?Bei strictly locking sperrst du die Datei exclusiv für dich, wenn du sie bearbeitest. Heißt niemand anderes hat zugriff darauf und kann sie ändern. So wird effektiv jeder Konflikt verhindert. Nachteil ist aber, das man von dir abhängig ist und warten mußt, bis du wieder fertig bist. Vergisst du das freigeben einmal... Alle Dateien sind bis zum Auschecken schreibgeschützt. (An eben diesen Schreibschutz hatte ich gedacht...) Beim optimistic locking können mehrere Entwickler gleichzeitig an den Dateien arbeiten. CVS bzw. SVN fügt danach die Änderung zusammen und meldet nur bei Überschneidung einen Konflikt, der manuell gelöst werden muß. Das hilft uns leider wenig, da es sich bei VIs leider ja um Binärdateien handelt. Wir haben ersteinmal mit dem optimistic locking angefangen, da es Default mäßig verwendet wird. Das strictly locking muß erst per Kommandozeile für das jeweilige Projekt aktiviert werden. Da wir nur maximal mit drei (nur in einem Fall, sonst zu zweit und meist an getrennten Projekten) Leute an einem Projekt arbeiten ist die Wahrscheinlichkeit, das wir an den gleichen Ecken Programmieren sehr gering. Gruß Oliver |