Setzt ihr Versionierungs-Tools für SW-Entwicklung ein ?

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.

> 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.

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.

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? ;-)

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).

Wir nutzen schon ewig Visual SourceSafe von Microsoft, es gab nie 
Probleme damit.

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.

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.

Ich schwöre auf GIT: http://www.youtube.com/watch?v=4XpnKHJAok8