|
Anzeige
|
[OT] welches Versionsmanagemetsystem für *.c Dateien
Gast
#180663
Hi,
ich benutze WINAVR
wie managt ihr Eure "release"-Stände beim Programmieren.
ich möchte mir "Meilensteine" merken, bei größeren Veränderungen
wieder zu diesen zurückkehren könne und mehrere Entwicklungsäste
aufmachen können
gibt es empfehlungen ( ausser Dateinamen per Notizblock festhalten :-)
?
Grüße,
Stefan
Ich verwende Subversion, das ist weit verbreitet und scheint sich als CVS-Nachfolger durchzusetzen. Die Bedienung per Kommandozeile ist sehr einfach, es gibt aber auch grafische Oberflächen und Plugins für viele Editoren.
Gast
#180665
Ich loese das pragmatisch mit zip-Archiven jeweils mit Datum und/oder Versionsnummer im Dateinamen. Dann bei "Arbeitsbeginn", vor jeder groesseren Aenderung und am "Feierabend" ein zip-Archiv mit allen Quellen/makefile etc. erstellen und direkt auf den Server/Wechselmedium sichern. Dies ist aber spaetestens dann, wenn man nicht alleine an einem Projekt entwickelt zu simpel und fehleranfaellig. Besser ein "richtiges" CVS (opencvs, sourcesafe etc.).
Gast
#180666
Ich kann Dir ebenfalls Subversion empfehlen, welches ich privat wie beruflich verwende. Am besten TortoiseSVN, es ist Subversion mit grafischen Einbindung in Explorer, was die Arbeit unheimlich erleichtert. Schneller Zugriff auf ältere Versionen, Vergleich der Sourcecodes mit älteren, uvm. (unbedingt Doku lesen) machen diesen Tool mit der Zeit unverzichtbar. Gruss Adalbert
Gast
#180667
Hi, danke, ich habe schon mal einen Blick auf die Doku geworfen - das scheint genau das zu sein was ich suche - und TortoiseSVN bringt dann noch ne gui dazu - was will man mehr ;-) Ich glaube ich Probier das gleich mal heute abend aus. Grüße Stefan
Gast
#180668
b.d.w.: was ist denn an der Frage off-topic? Im Gegenteil, endlich mal eine Frage, die eigendlich jeden überhalb des Anfänger-Levels interessieren sollte und bei der es nicht nur um Hausaufgaben-Betreuung geht ... Viele Grüße, Stefan
Gast
#180669
"Besser ein "richtiges" CVS (opencvs, sourcesafe etc.)" Besser nicht. Die beiden genannten System sind einfach zu alt und mit schweren methodischen Schwächen behaftet. Da andere Systeme (wie das genannte Subversion) auch nicht schwerer zu erlernen sind, lass bloss die Finger von den beiden. Bei kleinen Sachen fällt das noch nicht auf, aber wenn das mal grösser wird, dann steht man da und muss vieles von Hand gerade ziehen.
Gast
#180670
@ Stefan naja - off topic in so weit, als das es mit gcc eigentlich nicht wirklich zu tun hat - ausser das man seinen source damit managt ... .. grins .. Hausaufgabenbetreuung ... ich erinnere mich noch wie ich vor 20 Jahren mit einem Handbuch zu 6800 Assembler mir versucht habe das ganze beizubringen - es gibt heute viel zu viel fertig ... die jugend ist heute gar nicht mehr richtig gezwungen das hirn selbst zu bemühen ... Was man damals auf nem 64er oder nem zx 81 alles trixen musste ... Grüße, Stefan
Gast
#180671
Handbuch zu 6800-Assembler? War das auch von Rodney Zaks? (Der hatte mein 6809-Handbuch verfasst und hatte wohl auch 6502 und Z80 im Programm) Ich lege einfach bei jeder Produktionsversion ein Unterverzeichnis an und kopiere da sämtliche Sourcetexte und das fertige Hex-File rein. Zusätzlich zippe ich alles, falls mal doch jemand in diesem Unterverzeichnis editiert (Das Solaris-Netzwerk gestattet leider kein Setzen auf Read-Only unter Windows). Die Unterverzeichnisse benenne ich mit Datum und Versionsnummer, da ist das Wiederfinden ein Kinderspiel. Zwischenversionen beim Entwickeln nenne ich V1, V2 usw. und lösche sie dann am Ende. Ein zusätzliches Readme mit den Unterschieden zur Vorgängerversion macht die ganze Sache komplett. Und auch Kundenspezifische Versionen, die nicht mehr weitergeführt werden, sind kein Problem. Die Profis bei uns arbeiten mit CVS, aber das taugt nichts. Es steht zwar alles irgendwo drin, aber es ist unmöglich einen Versionsstand von einem bestimmten Datum wieder zu erzeugen. Man kriegt dann nur die Dateien, die an diesem Tag geändert wurden, aber nicht den Stand sämtlicher anderen Dateien. Es bestand mal die Notwendigkeit eine Kundenversion wiederherzustellen, wobei nur noch das Brenndatum des EPROMs bekannt war. Die UNIX-Profis habens tagelang versucht und mußten aufgeben. Sie haben dann irgendeine Version genommen und die Anpassungen nochmal neu geschrieben. Von CVS kann ich daher nur dringend abraten. Das Subversion muß ich mir mal ansehen, vielleicht ist das auch was für unsere Profis. Peter > Die Profis bei uns arbeiten mit CVS, aber das taugt nichts. > Es steht zwar alles irgendwo drin, aber es ist unmöglich einen > Versionsstand von einem bestimmten Datum wieder zu erzeugen. Das hast du schon einmal behauptet, und ich habe dir schon einmal gesagt dass es falsch ist. Die Option -D tut genau das. Außerdem gibt es Tags mit denen man bestimmte Versionsstände markieren kann und soll, wenn man ein Release macht. Mit deinem Verzeichnis-Verfahren tust du genau das was ein Versionsmanagement auch macht, nur fehleranfälliger, unübersichtlicher und langsamer.
Gast
#180674
Peter: Du und deine Profis sollten euch mal diese Bücher zu Gemüte führen: http://www.pragmaticprogrammer.com/starter_kit/vc/index.html
Gast
#180675
Hi,
vielen Dank für dne Tipp mit Subversion udn TortoisSVN - ich benutze
es mittlerweile.
vorallem die Shellintegration von TortoiseSVN ist genial.
Das erspart wirklich das Selbstversioniern - und mann kann schön einen
Komentar "mitabspeichern" damit man hinterher noch weis Welchen
Meilenstein man Erreicht hat ...
Grüße,
Stefan
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
