So ist es nicht gemeint, oder gewollt. Aber es macht aus meiner Sicht keinen Sinn eine Working-Copy ins SVN zu stellen, die noch nicht fertig ist. Ich frage mich nur, wer denn eigentlich noch am Projekt mitwirkt. So wirklich viel "andere" Bewegung ist aus meiner Sicht nicht mehr festzustellen. Beschäftigt sich wirklich jemand anders noch mit dem Quelltext ?
Hmm... SVN bietet doch prima Möglichkeiten, um neben funktionierenden Versionen ebenfalls noch "nicht funktionierende, weil gerade dran entwickelt wird"-Versionen einzustellen - Stichwort "Tags".
Und ich halte es für wichtig, das du deine Arbeit dort ablegst - erstens kann dir evtl. der eine oder andere dann noch zuarbeiten, zweitens sieht man vielleicht, dass es vorangeht, drittens ist deine Arbeit dann "gesichert" - sprich sollte Dir oder deinem Rechner samt Backups ($Gottheit/Höhere Gewalt behüte) etwas zustoßen, so gäbe es immerhin noch die Kopie im SVN, so dass Deine Arbeit weiterführt werden könnte.
bye
Einhirn
Das mit den Backups würde schon noch gehen :-) Da müßte noch so einiges mehr in Rauch aufgehen als mein PC. Das ist einer der Vorteile, wenn man beruflich mit IT zu tun hat...
Ich hatte schonmal überlegt nen tag dafür zu machen. Wobei das natürlich immer noch die Frage offen läßt, ob sich da überhaupt noch andere mit befassen werden. Werde die Tage nen branch anlegen und hochladen. Ein tag ist nach meinem Verständnis eher ein als "release" eingefrorener Versionsstand (wobei das im Zeitalter des svn technisch betrachtet genau das gleiche wie ein branch ist).
Tja, bei uns in der IT-Abteilung wird immer vermieden, dass über ein Projekt nur genau einer Bescheid weiß, und Passwörter werden an einem sicheren aber für bestimmte Mitarbeiter der IT-Abteilung zugänglichen Ort hinterlegt. Den Aufwand treiben wir - neben normalen Datenbackups - um auch für den Fall "Mitarbeiter von Omnibus überrollt, liegt jetzt glücklicherweise nicht tot, aber dummerweise mit Gedächtnisverlust im Krankenhaus" einen Ausweg haben und z.B. wichtige Systeme weiterhin gewartet werden können.
Ich warte gespannt - schließlich bin ich sehr an einem ZVEI-Decoder für Windows interessiert, den ich kostenlos erhalten kann - dafür würde ich auch mal in den Code gucken ;)
bye
Einhirn
So, branch 2.1.1-merginWinLin erstellt und meine working copy importiert.
Zur Zeit arbeite ich mit MSYS und Eclipse/CDT unter Windows XP.
./configure --enable-plugins
baut bei mir ein geeignetes Makefile. Unter Linux hatte ich - wenn ich mich nicht irre - noch ein paar Änderungen gemacht. Ich weiss nicht, ob ich die schon in der Windows working copy drin habe...
über aktive Mitarbeit würde ich mich freuen, da das ja auch ein Ansporn ist, die Sache bis zum Ende zu entwickeln ...
Hallo,
auf der Suche nach einem "simplen" ZVEI-Auswerter für unseren Betriebsfunk bin ich auf Monitor und die aktuelle Entwicklung gestoßen. Die Sourcen des 2.1.1-mergeWinLin habe ich ausgecheckt und mit MSYS kompilieren können. Das Binary ist lauffähig, seine TCP-Ports per Telnet erreichbar. Eine ZVEI-Tonfolge über das Mikrofon am Rechner auszuwerten gab jedoch nichts aus (nach Korrektur der monitord.xml -> eigene IP-Adressen als "ohne Login" eingetragen).
Bevor ich mich jetzt durch alle Sourcen wühle um den bisherigen Funktionsumfang herauszufinden: Gibt es irgendwo eine Liste der bereits implementierten Funktionalitäten des monitord und wo die echen Knackpunkte/Probleme noch vorliegen? Ich habe versucht, mir diese Infos aus den bisherigen Beiträgen dieses Threads herauszudestillieren, aber ich bin irgendwann stumpf gescheitert, wichtige Feature-Wünsche, Bugs und Fernziele von den bestehenden Features zu trennen :/. Die Sourcen sind dann doch recht umfangreich, von daher wären mir kleine "Pointer" sehr wichtig.
Für eine kurze Info darüber hier im Forum wäre ich sehr dankbar, dann wüsste ich genauer, ob und wo ich vielleicht helfen kann (oder ob nicht =)).
Viele Grüße
Martin
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)