SourceCode Verwaltung (SourceSafe / VisualSVN)

[SquattingBull]

Hallo Leute,

ich bin absoluter Anfänger was dass Thema Sourcemanagement betrifft und hoffe ihr könnt mir ein paar Fragen grob beantworten.

Zum Szenario:
Wir sind ein Team von knapp 10 Prorgammierern und entwickeln mehrgleisig in .NET Dialekten sowie VisualStudio 6. Alte VB6 Projekte werden mehr oder weniger nur gewartet und geupdatet, neue Aufgaben werden natürlich in .NET Solutions gelöst.

Nun möchten wir eine Quellcodeverwaltung migrieren, da wir desöfteren an unterschiedlichen Klassen der selben Projekte arbeiten und wir eine Versionierung, einen Verlauf und ein standartisierten Zugriff auf die Quellcodes sehr zu schätzen wissen.

Ein Produkt das mir sehr gut gefällt wäre VisualSVN / Subversion. Nun weiß ich allerdings nicht ob der VisualSVN Server .NET Solutions sowie VB6 Projekte verwalten kann? Die IDE sowie der Explorer wird über ein Plugin erweitert das die Bindung zum VSVN Server ermöglicht. Kennt sich damit jemand im produktiven Einsatz aus? Bekomme ich beide Entwicklungsumgebungen unter einen Hut (mit verschiedenen Plugins? Subversion für VB6 und VisualSVN für .NET?)

Eine weitere, weitaus teurere Option wäre Microsofts Visual SourceSafe.
Dadurch das es ein MS Produkt ist, bringt die IDE ihre eigene Schnittstelle zum SourceSafe gleich mit und muss nicht über ein Plugin ergänzt werden. Dadurch dass die Client relativ viel Spiel auf dem Server haben und VSS dadurch sehr anfällig für Clientabstürze ist, gefällt es mir nicht so gut wie das VSVN. Mal davon abgesehen kann ich nicht einschätzen in wie weit ich damit VB6 sowie .NET Sol verwalten kann.

Über eine kurze Aufklärung und evtl. eine individuelle Empfehlung auf Grund von Erfahrungen würde ich mich natürlich sehr freuen.

Beste Grüße und vielen lieben Dank,
Squat

 

[Boron]

Grundsätzlich ist es so, dass jedes KM-Tool (Konfigurationsmanagement) mit jeder Art Datei umgehen sollte. Selbst "Nicht-Text"-Dateien (Bilder, ausführbare Dateien (exe) usw.) können darin verwaltet werden.
Das ist bei CVS, SVN, ClearCase, Git... überall gleich und sollte bei SourceSafe auch so sein.

Will heißen, dass ihr eure Projekte mit jedem Tool verwalten könnt.
In dem Fall kann man dann ruhig zu SVN greifen, da es gut und frei ist.

Wir nutzen in der Firma ClearCase (von IBM/Rational). Aber nur weil das unser Mutterkonzern nutzt und wir scheinbar zu viel Geld haben. Wir sind sehr zufrieden .

 

[7H3 N4C3R]

SVN kann ich auch fast uneingeschränkt empfehlen. Wir setzen es schon länger erfolgreich in diversen Projekten ein.

Eine der Stärken von SVN ist das parallele Arbeiten, sprich es ist darauf ausgelegt ohne explizite Sperren zu arbeiten und Änderungen von mehreren Entwicklern intelligent zusammen zu führen. Keine Sorge, das funktioniert wirklich sehr gut. Ich hatte am Anfang auch arge Zweifel daran. Aber nachdem ich nun schon mehrere Jahre damit arbeiten, muss ich sagen es funktioniert bis auf Ausnahmen wirklich sehr gut. Und notfalls gibt es auch explizite Sperren. Davon abgesehen kann SVN jede Art von Dateien aufnehmen, wie Boron schon gesagt hat. VisualSVN wäre auch ein sehr einfacher "Out of the box" Einstieg, ohne ewig konfigurieren zu müssen.

Wenn Versionsverwaltung aber Neuland für dich ist, würde ich dir raten, dich ersteinmal aufführlich damit zu befassen. Insbesondere wenn ihr euch für SVN entscheidet - lies das SVNBook (zu finden auf der Subversion-HP) ausführlich. Gerade wenn die Bereiche Merging und Branching interessant sind, gibt es sehr viel was man wissen sollte. Bei Detailfragen - frag ruhig.

 

[Kantholy]

ich empfehle auch SVN... wenn du es dir leicht machen willst nimmste nen Windows Server, haust da VisualSVN Server drauf (is für lau) und verwaltest da deine ganzen Repositories... die alternative wäre du nimmst dir einen Windows oder empfehlenswerter Weise einen Linux Server und konfigurierst dir deinen Apache mit SVN zusammen, allerdings ist damit die Zugriffssteuerung nicht so geil wie mit VisualSVN, weil du hast halt keine GUI.

Ein weiterer Vorteil von VisualSVN: Es kann die Windows Authentifizierung nutzen, das is richtig geil, vor allem in einer Active Directory Umgebung.

Clientseitig würde ich TurtoiseSVN als Explorer Extension empfehlen und wenn ihr Visual Studio benutzt kannst du entweder auch VisualSVN als VS-Plugin benutzen, da musste halt Lizenzkosten blechen, oder: was ich dir empfehlen kann: AnkhSVN, ist auch eine VisualStudio Integration, kann das selbe wie VisualSVN und kostet NIX

und wie mein Vorposter schon zu sagen pflegte: Bei Detailfragen - frag ruhig

 

[SquattingBull]

Leute ihr habt mir SEHR geholfen! Vielen Dank!

Bei SVN hatte mir das Merging ein wenig Kopfzerbrechen gemacht, man ist halt nicht gewohnt dass das so rund läuft Allerdings nerven explizite Locks / ausgecheckte Files auch sehr und sind mir im Bereich Sharepoint schon des Öfteren mal auf die Füße gefallen.

Ich habe mich wohl für VisualSVN entschieden, da die Resonanz was die Verbreitung und Benutzung angeht sehr hoch ist (somit auch die Erfahrungswerte).

Ich verinnerliche jetzt erstmal sämtliche Infos, Dokumente und Papers die mir in die Hände fallen und würde im Falle des Falles gerne auf euch zurückkommen.

Nochmal Danke!

 

[7H3 N4C3R]

Vielleicht noch als kleine Warnung an dich:
VisualSVN einzurichten und zu benutzen ist erstmal easy aber keine Entschuldigung dafür, sich nicht auch spätestens mittelfristig mit der Kommandozeile zu befassen.
Es gibt noch viele spannende Fragen zu beantworten und Entscheidungen zu fällen. Vielleicht als Hinweis, bevor du ins Grübeln kommst: Nimm FSFS. (beim Lesen des SVN-Books wirst du darüber stolpern)
Jemand wird tiefes Wissen über Repository-Administration benötigen und ihr müsst euch für Verzeichnis-Strukturen entscheiden müssen. Der Vorschlag im SVN-Book einen Repository-Administrator zu benennen ist wirklich nicht untertrieben. Denn auch eine Versionsverwaltung will z.B. gebackupt werden etc. Außerdem werden Using-Guidelines benötigt, denn durch seine recht allgemeine Grundstruktur kann man in SVN auch viel Blödsinn machen.

Bevort du produktiv loslegst, arbeite dich hier durch: http://svnbook.red-bean.com/index.en.html und zwar Kapitel 1-7 von vorne bis hinten. Allen ernstes, auch wenn es ein wenig trocken wird. Nebenbei immer schön parallel mit Subversion die Kommandos ausprobieren und ruhig deine Kollegen zum Experimentieren und Rumspielen einladen.

 

[SquattingBull]

War schon abzusehen dass dieses Vorhaben nicht auf der linken Arschbacke abzusitzen ist!
Das SVN-Book verinnerliche ich zur Zeit und mein Team ist auch schon darauf vorbereitet sich (ebenfalls nach dem Lesen des Books) Gedanken über eine Verzeichnisstrukur zu machen. Nachträgliche Änderungen an grundlegenden Dingen wollen wir schließlich vermeiden.

Vielen Dank nochmal! Ein sehr schönes und spannendes Thema!

 

[Kantholy]

klar, auf die leichte schulter würd ich sowas vielleicht nicht umbedingt nehmen wenn man das produktiv in einem Unternehmen einsetzen will, aber 200 Seiten lesen wär mir zu persönlich zu viel...

Backups vom Repository sind auch relativ leicht, vor allem unter Windows, VSS sei Dank bekommt man da immer schön einen konsisten Zustand zusammen den man dann ohne weiteres wegsichern kann das ganze bekommt man ohne weiteres in 5 min mit Windowstools (ntbackup + planned tasks) hin :-)


eine Frage hätte ich aber mal: inwiefern machst du dir gedanken über verzeichnisstrukturen?! Ich hab das so gelöst:

Ein VisualStudio Projekt ist bei mir ein Repository, das ganze kommt dann so wie es ist ins Repo, ohne diese mistigen svn Ordner (tags,branches,trunk), von denen halte ich persönlich sowieso nicht viel

Kommt ein neues Projekt hinzu wird schnell ein neues Repository angelegt und fertig... normal ist dass ein selbstläufer^^

 

[olampl]

Hallo,

wir verwenden auch Subversion (vorher VSS).

Sind zufrieden damit, for allem gibt es mit ankhsvn auch ein sehr gutes Plugin fuer Visual Studio.

Achtung ab Tortoise version 1.6.2 ist der Dalily Build von ankhsvn zu verwenden.

lg

oli

 

[SquattingBull]

@Kant-holz:
Ja hört sich sehr pragmatisch an
Bin mir noch nicht ganz sicher, auf jeden fall erstmal ein wenig an einer Sandbox schauen was Phase ist. Wenns sich als tauglich erweist werden wir uns mit dem Aufwand was Verzeichnisse ect. angeht, auch beschrenken.

Wir pflegen Unternehmensweit eine ausgeklügelte Backupstrategie (inkl. Bandsicherung/Archiv), diese wird selbstverständlich auch auf die verwalteten Sourcecodes angewendet.

Gibt es grundlegende Bedenken den VSVN-Server auf einer virtuellen Maschine laufen zu lassen?

 

[7H3 N4C3R]

ohne diese mistigen svn Ordner (tags,branches,trunk), von denen halte ich persönlich sowieso nicht viel

Diese Ordner sind auch "nur" eine Empfehlung vom Subversion-Team und best practice, die sich nach eigener Erfahrung sehr gut bewährt. Wenn man es so will, kann man aber auch ohne die auskommen, auch wenn ich das wiederum nicht tun würde.

Gibt es grundlegende Bedenken den VSVN-Server auf einer virtuellen Maschine laufen zu lassen?

Nö. Machen wir auch und es funktioniert prima.

Backups kann man übrigens ganz einfach im laufenden Betrieb per svnadmin hotcopy ziehen.

 

[SquattingBull]

Nö. Machen wir auch und es funktioniert prima.

Backups kann man übrigens ganz einfach im laufenden Betrieb per svnadmin hotcopy ziehen.

Super!

Aber jetzt holt mich gerade die Bürokratie ein... Projektantrag ect...
Wenn wir es wirklich "richtig" machen wollen und der zum Rep-Admin ernannte Knecht nun alles von vorn bis hinten durchplanen und umsetzen darf, wieviele Manntage würdet ihr grob dafür einplanen?

 

[olampl]

wieviele Manntage würdet ihr grob dafür einplanen?

Haengt stark davon ab wie fit euer "Knecht" ist

 

[SquattingBull]

Ich formulier die Frage mal etwas sinnvoller, war nen bisschen ungünstig gewählt

Wieviel Zeit / Aufwand nahm es bei euch in eurem Umfeld in Anspruch? Diese Werte genügen mir völlig. Bezogen auf mein Szenario wäre es ohnehin wohl nur mutmaßerei... ihr wisst schon, selbsteinschätzung und sowas

Feierabend!
Gehabt euch wohl.

 

[olampl]

Habe gerade mal nachgefragt.

Bei uns betrug der Aufwand ca. 4 Wochen (rund 20 MT), die Einfuehrung erstreckte sich ueber ca. 5 Monate.
Wobei unsere Admins Hilfe aus der Entwicklung bekammen. (Das ist bei Projekten zu Beruecksichtigen, da hier Manpower abgezogen wird)

Zuerst wurden nur einzelne aktuelle/kleinere/neue Projekte auf SVN gezogen.

Erst nach dem einzelne User KnowHow aufgebaut haben um die Anfangsfallstricke zu meistern, haben alle Entwickler auf SVN gewechselt. (ca. 25 Entwickler)

Wir haben noch immer nicht alle Projekte Migriert (arbeiten sein rund einem Jahr mit SVN).
Das wird nur gemacht, wenn an diesen weitergearbeitet wird.

Hoffe konnte helfen,

lg
oli

 

[Kantholy]

also in so einem Umfeld mit 10-20 aktiven SVN Benutzern kommt man mit dem Arbeitsaufwand von 20 Manntagen glaub ich locker hin, und das von der Installation zur Integration bis hin zur Inbetriebnahme.

das schwierigste daran ist eigentlich den "Endbenutzern" zu erkären wie sie das System benutzen sollen.


zu der VM: Klar, das ist ein klassischer Virtualisierungskandidat, der Server hat quasi NIX zu tun, nur minimal IO auf Festplatte + Netzwerk beim ein und auschecken der einzelnen Benutzer, und sonst verhält sich das Teil wie ein stinknormaler Apache Webserver... ich hab unsere VM nur minimalst ausgerüstet, 1vCPU, 1GB Ram, 8GB OS Partition (Win2k3) + 50GB iSCSI "Daten" Partition und ich komm wunderbar damit zurecht.

Ach ja, wenn ihr dann eine Unternehmensweite Backupstrategie habt, dann würd ich sagen: macht euch das Leben leicht, und und benutzt den Fileserver den ihr sowieso schon habt um eure Repositories zu backuppen.
Im Windows Umfeld isses super easy, ich hab nur einen geplanten Task, der per xcopy /D nur inkrementell alle geänderten Datein nachts auf ein Netzlaufwerk von nem Server schiebt bevor da ne Stunde später die Bandsicherung angestoßen wird.

ACHTUNG! Was ich vermeiden würde ist bei der SVN Server Konfiguration die Repositories direkt auf ein Netzlaufwerk abzulegen.
Sonst könnts wieder Probleme mit dem Dienst geben dass der gestartet wird bevor das Netzlaufwerk verbunden ist... Genauso lustig isses wenn aus irgenteinem Grund das Netzwerk mal wieder Schluckauf hat

 

[7H3 N4C3R]

20 Manntage sind wohl realistisch, wobei man vielleicht noch dazu sagen sollte, dass die keinesfalls am Stück geplant werden sollten. Vielleicht 10 Tage am Stück, bis es rennt und der Rest kommt zwischendrin.
Und, den Schulungsbedarf der Mitarbeiter nicht vergessen. Dafür saßen bestimmt hochgerechnet alle Entwickler 2 Manntage zusammen.

 

[SquattingBull]

Männer ihr seid super, genau die Infos habe ich gebraucht.

Großes Lob an euch, muchas gracias!

 

[olampl]

Männer ihr seid super,

wissen wir

Happy implementing

 

[ape4711]

Hi Leute,

ich muss mich seit kurzem mit dem Thema Versionierung befassen, da ich mit zwei Leuten eine Projektarbeit an unserer Uni auf die Beine stellen muss.

Unser Prof hat uns hierfür VisualSVN vorgeschlagen.

Das klappt auch alles soweit ganz gut.

Ein schwerwiegendes Problem haben wir allerdings noch nicht lösen können und haben auch per Google nichts gefunden:

1. Unser Prof hat uns an's Herz gelegt, zum gemeinsamen Arbeiten die "Lock"-Funktion zu verwenden.
Das Problem hierbei ist: Wenn eine Datei durch Person_1 gelockt ist, kann Person_2 die Datei nach einer Änderung zwar nicht Commiten. (Soll ja so sein) Hat Person_1 seine Arbeit beendet, commited und das Lock aufgehoben, macht Tortoise logischerweise Probleme, wenn Person_2 seine Arbeit jetzt commiten möchte.
Wie kann ich dieses Problem lösen?

2. Wenn ich trotzdem die Branch/Merge-Funktion verwenden möchte habe ich doch das Problem, dass in so einem VisualStudio Projekt jede Menge automatisch generierter Code entsteht. Wie soll dieser Code denn dann gemerged werden?

Ich würde mich wahnsinnig darüber freuen, wenn mir jemand helfen kann!