Hi, sind Euere Projekte so groß, dass es Sinn macht Versionierungs-Tools einzusetzen? Ich entwickle unter Windows XP mit Win-AVR-GCC (nicht kommerziell - nur Hobby) an verschiedenen (ähnlichen) C-Projekten gleichzeitig (Uhr, Bewässerungscomputer, Rolladensteuerung, ...) Dabei laufe ich in Versionsprobleme. Z.B. fällt mir während der Programmierung der Rolladensteuerung ein "tolles Gimmick" ein, welches ich unbedingt in meiner Uhr auch verwenden möchte ... Schon ist das Durcheinander da. Mit einem Versionsverwaltung (so stelle ich mir das vor) müsste es doch einfacher gehen? Setzt Ihr sowas ein ? Gruß Andreas
Schon mal Bibliotheken erstellt ??? Würde einiges vereinfachen :-)
auf der Arbeit setzen wir jetzt Subversion ein, das gefällt mir ganz gut. Vor allem da mehrere Leute an einem Projekt arbeiten ist das unerlässlich. Aber auch für kleine Projekte sehe ich durchaus Vorteile und werde das jetzt für den AVR 'Bastelkram' installieren. Je früher man sich an den zusätzlichen Aufwand gewöhnt desto besser. Die Bibliotheken lösen das Chaos nicht. Im Gegenteil, eine Lib für ein neues Projekt B erweitert ist dann vielleicht inkompatibel zu einem älteren Projekt A oder der zusätzliche Code macht die neue ganz einfach zu gross. Mit der Versionsverwaltung macht einen Schnappschuss der verwendenten Lib und kann die mit einem Klick wieder restaurieren.
Ich nehme seit Urzeiten für alles, auch für persönlichen Kleinkram, CVS. Wenn ich jetzt anfangen müsste, würde ich vermutlich auch mit SVN anfangen, aber da ich mit CVS groß geworden bin, stören mich dessen Nachteile in diesem Bereich noch nicht so gravierend, dass ich das alles umstellen würde. Eine Arbeit ohne Versionsverwaltung kann ich mir nicht mehr vorstellen. (Eine Arbeit ohne nächtliches Backup auch nicht. ;-)
Früher CVS, jetzt subversion. Beruflich schon mal ClearCase, aber das ist m.E. für die meisten uC Projekte mit Eulen auf Spatzen geschossen.
> sind Euere Projekte so groß, dass es Sinn macht Versionierungs-Tools > einzusetzen? Ich setze es auch für kleine Projekte immer ein. Ich finde, wenn man auch nur halbwegs ernsthaft programmieren will, führt kein Weg daran vorbei. Mir geht es hier wie Jörg. Ich benutze CVS, würde aber vermutlich SVN benutzen, wenn ich jetzt neu anfangen würde.
>... mit Eulen auf Spatzen geschossen.
Eulen trägt man nach Athen.
Die Spatzen werden mit Kanonen erschossen.
Schönes Ding :-))
Zu, Thema:
Ich mache auch den kleinsten Frickelkram immer nur "MIT".
Es lohnt sich immer und der vermeintliche Mehraufwand ist
lächerlich im Vergleich zu "verlorenem" Quellcode.
Ganz konkretbei mir: MS Source Safe.
Und zwar, weil wirs eh wegen dem Visual Studio benutzen.
> sind Euere Projekte so groß, dass es Sinn macht Versionierungs-Tools > einzusetzen? Jedes Projekt ist groß genug dafür. Ich verwende selber SVN und Darcs. Für Windows würde ich SVN empfehlen. Wenn man gerne auf der Kommandozeile arbeitet ist Darcs komfortabler. > Z.B. fällt mir während der Programmierung der > Rolladensteuerung ein "tolles Gimmick" ein, welches ich unbedingt in > meiner Uhr auch verwenden möchte ... Schon ist das Durcheinander da. Das Abgleichen von Änderungen zwischen verschiedenen Projekten ist auch mit einer Versionsverwaltungssoftware nicht ganz einfach. CVS und SVN (zumindest < 1.5) bieten da keine große Hilfe.
Ich setze Versionierungs-Tools sowohl beruflich (früher MS SourceSafe (ein Graus), jetzt Subversion) als auch im Hobby (früher CVS, jetzt ebenfalls Subversion) ein, aber nicht um komplett neue Features von einem Projekt in ein anderes zu übertragen, sondern hauptsächlich als "Zeitmaschine", um jederzeit beliebige ältere Versionen einer Software wiederherstellen zu können. Von den Programmen, die's für umme gibt, ist wohl Subversion (SVN) derzeit neben CVS das verbreitetste und wird dieses nach und nach ersetzen.
> mit Eulen auf Spatzen geschossen
Wer mit Eulen schießt, dem fliegen sie zuerst um die Ohren und dann ins
Gesicht.
Hinterher ist der Schütze blind und macht nie wieder solche Dummheiten.
Ich kenn mich da aus...
Immer noch besser als Kanonen nach Athen getragen :)
Wie habt Ihr Euch in Subversion eingearbeitet? Haben die meisten von Euch ne Einführung in der Firma bekommen oder gibt's ne Quelle für ein gutes Einsteigertutorial? ;-)
Installieren und bedarfsweise die hilfe aufrufen. Wer schon mal mit Konfigmgmtsystemen gearbeitet hat, sollte mit svn keine Probleme haben.
Mit SVN habe ich noch nicht oft gearbeitet. Zu CVS habe ich mir ein Buch gekauft und durchgelesen. Über SVN gibt's auch Bücher. Ich denke, das ist auch ganz sinnvoll, wenn man vorher noch gar nicht mit Revisionsmanagement-Systemen zu tun hatte. Es gibt aber bestimmt auch gute Tutorials im Netz.
http://svnbook.red-bean.com/ Es hat allerdings das gleiche Problem wie alle anderen Bücher auch: Man muß sie lesen ;)
>> Z.B. fällt mir während der Programmierung der >> Rolladensteuerung ein "tolles Gimmick" ein, welches ich unbedingt in >> meiner Uhr auch verwenden möchte ... Schon ist das Durcheinander da. >Das Abgleichen von Änderungen zwischen verschiedenen Projekten ist auch >mit einer Versionsverwaltungssoftware nicht ganz einfach. CVS und SVN >(zumindest < 1.5) bieten da keine große Hilfe. Naja, zumindest die SVN-externals können da schon einen Schritt weiterhelfen - soweit einem da ein Versionierungstool überhaupt helfen kann. SVN ist allerdings nur die halbe Miete, du brauchst auch noch einen SVN-Client, um die Dateien vernünftig ein/auszuchecken. Dafür nimmt man unter Windows den TortoiseSVN. Der integriert sich ins Kontextmenü des Explorers und man muss sich nicht an eine neue Oberfläche gewöhnen, sondern kann direkt aus dem Explorer heraus Dateien verwalten. Ich bin vor einigen Monaten ebenfalls von CVS auf SVN umgestiegen. Und gerade die externals habe ich zuvor sehr vermisst (bzw. übersehen falls es das schon bei CVS gab :-). ----, (QuadDash).
---- wrote: > Naja, zumindest die SVN-externals können da schon einen Schritt > weiterhelfen - soweit einem da ein Versionierungstool überhaupt helfen > kann. Externals bringen da eher wenig. Beim Abgleichen von Änderungen zwischen verschiedenen Branches (oder auch verschiedenen Repositories, manche Systeme wie z.B. Darcs machen da keinen Unterschied) ist Merge Tracking sehr hilfreich. SVN beherrscht das im Gegensatz zu den meisten Konkurrenten leider noch gar nicht, erst für Version 1.5 ist etwas geplant.
Wir nutzen schon ewig Visual SourceSafe von Microsoft, es gab nie Probleme damit.
LoL wrote: > Wir nutzen schon ewig Visual SourceSafe von Microsoft, es gab nie > Probleme damit. Da habe ich aber von anderen auch schon komplette Horrorstories drüber gelesen. (Weiß nicht mehr genau wo, ich glaube, es war auf avrfreaks.) Von wegen mehrfach komplett zerschossene Datenbank, jeweils mit Rückspielen von Tape-Backups nur zu reparieren (und entsprechendem Verlust eines Teils der jüngeren Geschichte).
Der Schwachpunkt bei SourceSafe ist, dass es im Gegensatz zu den meisten anderen Versionsverwaltungssystemen keinen zentralen Server gibt, der die Zugriffe auf das Repository prüft und koordiniert. Das Repository ist einfach eine Verzeichnisstruktur, die von den "Clients" per Dateifreigabe in eigner Verantwortung gelesen und beschrieben wird. Deswegen müssen den einzelnen angeschlossenen PCs volle Zugriffsrechte auf dieses Verzeichnis gewährt werden. Ein einzelner PC im Netzwerk, auf dem nicht alle SourceSafe-Bugfixes installiert sind, kann somit das komplette Repository unbrauchbar machen. Aber auch andere (fehlerhafte) Anwendungen können durch Zufall (bspw. beim Bearbeiten von Verzeichnisbäumen) in das Repository gelangen und dort Schaden anrichten, weil sie natürlich die gleichen Zugriffsrechte haben wie das SourceSave-Programm selbst. Bei serverbasierten Versionsverwaltungssystemen muss jede Transaktion auf dem Repository den Server durchlaufen, es gibt keinen direkten Zugriff auf das Repository. Der Server führt zumindest einige Plausibilitätschecks auf die Anfragen durch, bevor er sie ausführt. So führen fehlerhafte Clients schlimmstenfalls zu neuen Releases mit seltsamem Inhalt (die auch wieder gelöscht werden können), sie zerstören aber nicht die Repository-Struktur. Fairerweise muss man dazu sagen, dass solche Repository-Crashs in SourceSafe relativ selten auftreten. Wenn es aber doch einmal passiert, ist meist ein Teil der Historie verloren und das Geheule groß. Da helfen weder regelmäßige Backups noch RAID-Systeme. Abgesehen von der mangelnden Datensicherheit fehlen dem SourceSafe einfach ein paar Features, allen voran die Verwaltung von Branches, die für ein professionelles Release-Management unabdingbar ist. Das Programm ist halt doch schon etwas älter und wurde, wenn ich das richtig gehört habe, von MS inzwischen durch etwas moderneres ersetzt.
M$ benutzt SourceSafe garantiert nicht für seine Produkte. Das Teil war schon vor Jahren unter aller Kritik und hat sich seither wohl nicht wesentlich gebessert.
> M$ benutzt SourceSafe garantiert nicht für seine Produkte. Dieser Meinung bin ich auch. Man muss sich nur mal die Microsoft Visual SourceSafe Best Practices auf http://msdn2.microsoft.com/en-us/library/Bb509342(VS.80).aspx durchlesen. Das alles liest sich ein wenig wie "Wenn ihr das Tool unbedingt benutzen wollt, tut es auf eure Verantwortung. Aber sagt hinterher nicht, wir hätten euch nicht gewarnt!" Schon der erste Satz erweckt volles Vertrauen: Under normal operation in a stable environment, Microsoft Visual SourceSafe provides excellent storage and security for your current source data and past revisions. However ... Und so geht's weiter: Under normal use, your Visual SourceSafe database should not exceed 3 to 5 GB. Für die Entwicklung des Windows-Betriebssystems selbst scheint SourceSafe also etwas schwachbrüstig zu sein. Use the Analyze tool shipped with Visual SourceSafe to detect and repair problems in the database structure. When you run Analyze regularly, especially in high-use situations, you can discover small problems and fix them before they become worse. Run Analyze weekly or, at a minimum, monthly, as part of regular maintenance. Die Korruption passieren also häufiger und sind dazu noch schleichend. Running out of disk space in the middle of a complex operation can create serious database corruption. Der Verlust der letzten Transaktionen wäre ja verständlich. Aber muss deswegen gleich die ganze Datenbank zerschossen werden? The Ss.ini files of users are limited to 64 KB and a maximum of 10 different computer-specific settings. ... If you are experiencing unusual user-specific problems, try deleting unnecessary entries in the user's Ss.ini file. MSDOS und 8086 lassen Grüßen. Synchronize the dates and system clocks for all Visual SourceSafe client computers with the Visual SourceSafe server. This prevents check-in and check-out operations from appearing to happen out of sequence and affects any labels that are applied. Eine weitere Konsequenz des serverlosen Konzepts. Aber nun ist genug drauf rum gehackt. Das Teil ist alt und überholt, da wird auch nichts mehr geflickt. Zum Glück gibt es für jeden Geldbeutel genügend Alternativen.
Wozu Versionierung ?? Schmeiss den alten Schei** weg und nutze Deine neue Bibliothek. Am besten proggste so, dass jede wichtige Funktion in nem extra Modul ist und dann stellste je nach Anforderung einfach die gewünschten "Gimmiks" zusammen, da nicht jeder Furz in jede Anwendung muss.
Hält die Programme klein und lässt sich leichter pflegen ....
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.