Alternative zu Sourcesafe

[Tactive]

Hallo Programmierfreunde,
wollte mal wissen ob Ihr mit eine gute Alternative zu Visual Sourcesafe nennen können. Wichtig dabei sollte vor allem eine
einfache Integration/Verwendung im Visual Studio 2005 sein. Hat hier vielleicht jemand praktische Erfahrung mit dem EInsatz
von Subversion und AnkhSVN oder VisualSVN?? Wäre gut wenn mir jeman hier was drüber berichten könnte. Wir setzen auf der
Arbeit noch das Sourcesafe ein, aber da es keine Möglichkeit für Versionierung bzw. Tagging bietet - kann man das eigendlich
knicken.

[dowhilefor]

Ich bin großer Fan von Subversion, allerdings AnkhSVN vor ewigkeiten mal getestet und mir, aus eigener Blödheit, großteil meiner Sourcedateien vernichtet. Spricht aber nichts gegen Ankh. Ich persönlich bevorzuge aber TortoiseSVN oder eben direkt svn auf der Kommandozeile. Wovon ich momentan immer häufiger höre ist noch Git könnt ihr euch ja auch mal angucken ob das mehr bringt selbst hab ich es aber noch nie benutzt, schadet aber nie die Konkurrenz zu kennen :)

[Aramis]

Ich nutze Mercurial, und bin ziemlich zufrieden damit. Wie es da allerdings mit der Integration in Visual Studio aussieht - keine Ahnung, die Integration in den Windows-Explorer via TortoiseHG ist noch nicht ganz so weit entwickelt wie TortoiseSVN. Dafür hat Mercurial ein paar Vorteile ... u.a. gibt es keinen zentralen Server, den man regelmäßig backupen müsste.

AnkhSVN hab ich zum letzten Mal vor einem halben Jahr probiert. Probiert, und nach einem Tag wieder deinstalliert. Plötzlich führten ganz harmlose Dateikommandos (z.B. Umbenennen) in Visual Studio zu komischen und unreproduzierbaren Fehlermeldungen, ganz mal davon abgesehen dass die Software auch gelegentlich kleine Hänger hatte und ein (imho) unintuitives Interface pflegt. Ob's mittlerweile besser ist - keine Ahnung, ich würde definitiv TortoiseSVN bevorzugen und auf die Integration in VS pfeifen. Denn dann gibt es bei jedem kleinen VS Update oder Upgrade auf eine neuere Version potentiell Probleme.

[VizOne]

Ich benutze Subversion, TortoiseSVN und VisualSVN. Ich halte eine vernünftige Integration in VisualStudio für sinnvoll bis absolut notwendig, da man sich ansonsten recht schnell das Arbeitsverzeichnis kaputt macht, etwa wenn man Dateien umbenennt oder verschiebt, ohne das dem Arbeitsverzeichnis ordnungsgemäß mitzuteilen. Mit VisualSVN bin ich sehr zufrieden und habe kaum Probleme damit. Kann ich wirklich empfehlen. Ab und an vergisst VSVN neue Dateien automatisch zu adden, aber das wars dann auch schon. Achja, Visual SVN Server ist natürlich noch ein nettes extra um die Repositories zu verwalten und auf einfachste Manier über HTTPS zu Verfügung zu stellen.

Git, bzw. verteilte VCSs im Allgmeinen hören sich ja nicht schlecht an, solange die Integration in Windows/VS aber noch nicht das Niveau von TortoiseSVN bzw. VisualSVN erreicht hat, werd ich wohl mal erst bei svn bleiben. Vor allem, wenn man selber vollen Zugriff auf das Repository hat, sind die Vorteile eines verteilten VCS (z.B. lokale Commits) auch nicht mehr soooo groß. Ist halt praktisch, wenn man nur Lesezugriff auf das Masterrepos hat und lokal mal ein paar Sachen probieren will, dann sind lokale Commits schon nichts schlecht.

[kimmi]

Ich benutze SVN mit TortoiseSVN und gezwungendermaßen ClearCase ( eine kommerzielle Lösung von IBM, teuer, langsam und SchXXXXX ). Svn kann ich empfehlen, wenn ein zentraler Server reicht. Ansonsten würde ich genau wie Aramis zu Mercurial raten. Git ist meines Wissens unter Windows noch nicht so gut unterstützt und dementsprechend gewöhnungsbedürftig in der Anwendung.

Gruß Kimmi

[Sternmull]

Ah, ein Leidensgenosse! :-)

Auf Arbeit wird bei mir auch SourceSafe verwendet. Vor ein paar Monaten wurde ich mit Aufgaben betraut die tiefgreifende Änderungen an einem sehr großen Teil des Quelltextes erforderten. Nachdem ich die ersten paar Schritte im gemeinsam genutzten SourceSafe Repository gemacht hatte war klar das es so nicht geht. Da Branches in SoruceSafe praktisch nicht realisierbar sind habe ich alle Änderungen im Haupt-Entwicklungszweig gemacht und die normale Entwicklung gefährdet.
Neben SourceSafe war ich damals ausschließlich mit SVN halbwegs vertraut (durch Studium und Hobbyprojekte). Also habe ich als erstes versucht meine Entwicklung parallel im mir vertrauten SVN zu verwalten und die anderen im SourceSafe in Ruhe zu lassen. Allerdings war ich zu diesem Zeitpunkt auch schon neugierig was GIT denn so zu bieten hat. Also hab ich damit nebenbei rumprobiert. Letzten Endes bin ich dann komplett auf GIT ausgewichen und hab SVN links liegen lassen. Das hatte unter anderem folgende Gründe:

• - SVN war recht träge. Vielleicht wars auch nur TortoiseSVN, aber abfrage vom Log, von Diffs und auch das Commiten selbst hat in dem Projekt was ca. 6000 Dateien umfasst schon so lange gedauert hat das es mich genervt hat
  - Merging ist zwar mittlwerweile halbwegs gut unterstützt, hat mir aber aus früheren Aktionen mit SVN doch irgendwie Unbehagen bereitet
  - Die ganzen .svn Verzeichnisse von SVN haben mich gestört
  - Ich geb zu das ich zu einem großen Teil auch einfach neugierig war was GIT zu bieten hat, da es ja mit einem sehr unterschiedlichen Konzept arbeitet

Meine positiven Erfahrungen mit GIT (verwendet unter Windows Vista, 32bit):

• - Als GUI nehm ich TortoiseGIT was auch ganz ok ist. Allerdings mach ich alles außer Commits, Diffs und Merges auf der Kommandozeile (also z.B. Checkouts, Verwaltung von Branches etc.).
  - GIT ist schneller als SVN. Und das obwohl es angeblich unter Windows schlechtere Performance haben soll als unter Linux.
  - Das eine .git Verzeichnis im Basisverzeichnis der working direktory ist mir wesentlich sympathischer als die ganzen .svn-Verzeischnisse in jedem Unterverzeichnis
  - In dem .git Verzeichnis ist die Gesamte History drin wordurch man das Repository komplett ohne Kontakt zu einem Server verwalten kann. Aber selbst bei sehr großen Projekten die ich mir angesehen habe war das .git Verzeichnis kaum größer als eine aktuelle Arbeitskopie.
  - Lokale Branches und Commits sind richtig praktisch. Man kann seinen Unfug in eigenen Branches treiben die keine anderer zu Gesicht bekommt. Erst wenn man was brauchbares hat bietet man es zur Integration in die offizielle Entwicklung an. Man kann seine lokale History korrigieren oder komplett umorganisieren. Also keine Commits mehr in denen sowas steht wie "Hier noch die Dateien die ich im letzten Commit vergessen hatte.", denn so was kann man bei sich ausbessern bevor es anderen auf die Nerven geht.
  - Branches können nahtlos von einem Repository in ein anderes übernommen werden, die Komplette Histroy bleibt dabei natürlich erhalten.
  - Ich brauch GIT nicht mitteilen wenn ich eine Datei verschiebe. Solange ich die Datei nicht gleichzeitig verändere sieht GIT von selber das es die gleiche Datei ist die nur verschoben/umbenannt wurde.

Und hier noch ein paar negative:

• - GIT ist komplexer als SVN und SourceSafe. Ich weiss nicht ob es daran liegt das verteilte Versionsverwaltung noch relativ neu für mich ist, oder ob GIT es vielleicht auch ein bisschen komplizierter macht als es sein müsste. Was ich so im Netz gelesen habe müssen auch erfahrende GIT-User regelmäßig in der Dokumentation nachschlagen. Ich hab auf jeden Fall eine ganze Weile Einarbeitungszeit gebraucht.
  - für GIT gibt es (noch) nicht so viele tolle Tools wie für SVN. Owohl ich momentan mit TortoiseGIT und Kommandozeile eigentlich ganz zufrieden bin. (Wenn ich's mir überlege hab ich bei SVN auch nur TortoiseSVN und (seltener) die Kommandozeile verwendet)
  - es scheint nichts Fertiges zu geben das mir einen GIT-Branch und ein SourceSafe Repository bidirektional synchronisiert. (damit man in der Übergangsphase SoruceSafe und GIT parallel nutzen kann)

Unterm Strich bin momentan mit GIT sehr zufrieden und finde solche Features wie lokale Commits, persönliche Branches, Rebase, Stash etc. extrem nützlich obwohl ich momentan alleine mit meinem GIT-Repository arbeite (was aber dennoch diverse Branches hat). Die Realisierung von Branches in verteilten Versionsverwaltungssystemen finde ich auch wesentlich sinnvoller als es z.B. in SVN der Fall ist. Und da ich mittlwerweile auf den Trichter gekommen bin wie ich durch die ganzen Branches produktiver und arbeiten kann, und gleichzeitig bessere Qualität dabei abliefere, werde ich bei verteilter Versionsverwaltung bleiben. Ob GIT das non plus ultra in diesem Sektor ist kann ich nicht 100% sagen. Aber es ist meinem Eindruck nach der populärste Vertreter und kann alles oder mehr was die anderen können. Ein Blick lohnt sich auf jeden Fall, auch wenn man vielleicht etwas länger hingucken muss bis man wirklich produktiv damit arbeiten kann.

Ich setze mich derzeit auf Arbeit dafür ein die SourceSafe-Lösung durch GIT abzulösen. Daher würde es mich brennend interessieren was andere mit diesem Thema für Erfahrungen gemacht haben und welchen Problemen sie dabei begegnet sind.

[Tactive]

Naja, wir haben auch mal einen SVN Server aufgesetzt und ein kleines Testprojekt eingespielt. Zum Testen haben wir dann AnkSVN für das Visual Studio installiert und mit 2-3 Leuten probiert. K.O. für dieses Szenari war dann als beim Mergen der Quellcode im Repository total geschreddert wurde. Das war der Designer - Quellcode den es da zerhauen hat. Schade eigendlich.
Tools wie TortoiseSVN habe ich vorgeschlagen fand aber keinen Anklang. Bei meinen vorherigen Arbeitgebern habe ich in Java mit Eclipse programmiert. Da wurde jeweils CVS verwendet was auch keine Probleme machte. Vor alle das man auf mehreren Branches arbeiten kann ist echt nützlich. Im Soucesafe kommt man eigendlich nicht umher seinen Projektstand zu gefähren weil man nur einen Entwicklungsstand hat.