Suche Versionsverwaltung für .NET UND VB6

Derzeit nutzen wir Microsoft SourceSafe (Version 6) als Versionsverwaltung für unser Produkt. Das Produkt besteht aus einem Kern, der in VB6 programmiert ist, und aus diversen kleineren Projekten, die in VB6 und .NET programmiert sind.

Da SourceSafe alles andere als benutzerfreundlich und aktuell ist, sind wir auf der Suche nach einem neuen Versionsverwaltungssystem. Ich habe mir schon diverse Systeme angeschaut (darunter auch TFS, SVN und Git), allerdings waren alle nicht wirklich geeignet, da man damit den VB6-Code nicht wirklich gut verwalten kann.

SourceSafe hat noch den Vorteil, dass es eine Integration in die IDE für VB6 und ins Visual Studio gibt. Das ist aber nicht so das Problem. Das größte Problem ist, dass das Branchen von VB6-Code mit diesen Systemen nicht möglich ist. Zumindest nicht, ohne manuell Dateien hin und her zu kopieren.

Aber vielleicht hat je jemand eine ähnliche Erfahrung gemacht. VB6 ist ja durchaus noch weit verbreitet.

Du hast dir Git anscheinend nicht genauer angesehen.
Ich sehe keinen Nachteil bei Git, unabhängig von der Programmiersprache.
Turtoise Git für die Explorer integration und im Studio per Plugin.
Ich verstehe auch nicht wo das Problem beim branchen, speziell bei vb6, sein soll.

Perforce hat eine (für mich) eigenartige Weise, wie es sich im Checkin verhält(Versionierung pro Datei oder pro Label, nicht pro Gesamtstand).
Aber VB6 soll zu "100%" unterstützt sein, auch in der IDE.

Ich nutze Perforce wie auch TFS/Git - bevorzuge aber allein aufgrund der Bedienung zweiteres.

Du hast dir Git anscheinend nicht genauer angesehen.

Ich habe da kaum Erfahrung, und Git ist nicht so einfach auf Anhieb zu verstehen. Werde das aber nächste Woche mit einem erfahrenen Git-Benutzer ausprobieren.

Ich nutze Perforce wie auch TFS/Git - bevorzuge aber allein aufgrund der Bedienung zweiteres.

Heißt das, dass Du auch VB6-Code im TFS verwaltest? Wenn ja, wie klappt das mit den Branches?

Ne, ich mach nur .NET. Aber ich meine, dass einige meiner Kollegen noch VB6 nutzen bzw. genutzt haben.
Ich weiß aber, dass Perforce sich in die VB6 IDE integrieren kann P4: Microsoft Visual Basic
Bezüglich den Funktionen ist das ja sowieso Sprachenunabhängig; wüsste nich, was es da bei VB6 besonderes geben soll. Branches laufen hier eben auf Labels und fertig.

Ich wüsste auch nicht, warum branches mit SVN bei VB6 nicht gehen sollten.

Hallo zusammen,

SVN sollte ziemlich egal sein, mit was du ankommst (C#, VBx,...). Es gehen branches, merges und und und. Und es ist kostenlos. Hoster dafür wären Zb. "Assembla" und Co. oder eben privat auf deinem NAS 😉 Für VisualStudio wären dann AnkhSVN und dazu TortoiseSVN da. VisualSVN ist, so glaube ich, kostenpflichtig.

Private benutze ich auch für Projekte TFS. Bin begeistert davon. Jedoch alles mit C#. Aber mit VS 2012 klappt das schon sehr gut.

Gruss

Coffeebean

Hallo,

auch ich habe so meine Verständnisschwierigkeiten, warum ein Subversion nicht mit VB6 Sourcen klarkommen soll - dem Subversion ist es nämlich fürchterlich Schnuppe, was man ihm für Dateien an den Kopf wirft. Ob das nun C#, VB, Assembler, Java, COBOL oder sonstwas ist, es behandelt alles gleich.

Wie dem auch sei.... Du hast Dir eigentlich die zwei richtigen Kandidaten rausgesucht (zumindest wenn man kein Geld in die Hand nehmen will/kann/darf).

Subversion ermöglicht eigentlich einen recht zügigen Einstieg und ist meist einfach zu bedienen. Es gibt mit TortoiseSVN eine gute Explorer-Integration und verschiedene Add-Ins für Visual Studio (kostenlos ist dann AnkhSvn). Subversion verfolgt den Ansatz, dass es immer einen zentralen Server gibt (also geben muss) den man für Checkouts, Merges und/oder Commits erreichen können muss.

Git ist zur Zeit "der König" der dezentralisierten SCMs (wie gesagt - zumindest bei den kostenlosen Angeboten). Die Lernkurve ist verhältnismäßig hoch, zumindest im Vergleich zu Subversion o. ä., da es halt vom klassischen Client-Server abrückt und daher erst einmal ein Umdenken notwendig ist. Die Kommandozeile ist da auch nicht jedermanns Sache 😉 Aber auch für Git gibt es inzwischen für Windows nette Tools wie z. B. SourceTree oder auch TortoiseGit. Und natürlich gibt es auch eine Integration für Visual Studio, z. B. den Git Source Control Provider oder eine Integration in den Team Foundation Server (die Visual Studio Tools for Git).

Man muss sich halt entscheiden was man will: Will mann auch ohne Verbindung zum Server seine Änderungen am Code committen können (z. B. im Urlaub oder während einer Bahnfahrt)? Dann ist ein dezentralisiertes System wie Git unverzichtbar......

bye,
Michael

Für TFS gibts ne kostenlose Cloudversion (http://tfs.visualstudio.com, nutze ich auch, klappt super! - gibts als TFS als auch als TFS+Git und funktioniert mit der Serverkommunikation wie auch als local branch) und auch für perforce als lokale Installation (bis 5? User).

Stimme ich Abt zu: Das klappt echt gut.

Vielleicht ein wenig offtopic: Die 5 User als Maximum sind erstmal angegeben, weil es noch kein Pricing-Modell gibt. Momentan gehen auch mehr. Wenn eins kommt und man mehr als 5 User drin hat wird wohl eine Mail kommen, von wegen: "Schmeiss alle bis auf 5 raus, sonst kostet es was". Im Moment gehen also auch noch mehr als 5 User.

Gruss

Coffeebean

Wären mehr Lizenzen notwendig. Aber das ist nicht mein Bier.
Cloud-Lösung wird wohl aber nicht gefragt werden, da das Unternehmen seinen Quellcode ungern nach außen frei gibt.

Hallo GambaJo,

was spricht dann gegen einen internen SVN-Server?

Gruss

Coffeebean

Im Prinzip nichts.
Ich meine mich aber erinnern zu können, dass das Mergen dort nicht so einfach war. Eine der wichtigeren Anforderungen ist nämlich, dass man Quellcode-Dateien nicht mehr exklusiv auscheken muss.

Ok, ich habe noch mal recherchiert.
Git wäre sehr wohl problematisch, da in VB6 die Forms in der Regel aus zwei Dateien bestehen, und eine davon ist binär. Die kann man nicht mergen.
In SVN ginge das, da man für diese eine Regel aufstellen könnte, mit der man diese Dateien exklusiv auscheckt.

Für den TFS gibt es auch ein PlugIn und einen Provider, mit dem die Anbindung VB6 zu TFS klappen würde. Wie das allerdings mit den Branches klappt, steht nirgendwo.

Also, meine VB6 Zeiten sind unendlich lange her, aber ich kann mich nicht daran erinnern, dass die Forms binär waren. Höchstens die Resourcen-Dateien. Aber sobald es Binär wird, hat man das Problem bei jeder Sprache mit jedem VCS.

Wegen den TFS und Branching: Einfach mal nach "TFS Branching Guide" suchen.

Hi,

ich habe noch nie so richtig mit VB6 programmiert - aber wenn ich mich richtig erinnere, dann werden diese binären Dateien vom Resource Compiler erstellt - sprich, es gibt "leserlichen" Code dazu und nur dieser gehört ins SCM.... Dann kannst Du prima mergen und VB merkt nach dem Merge dass es die Resourcen neu bauen muss....

Bye,
MK

Forms bestehen aus *.frm ud *.frx Dateien. Die frx-Dateien sind binär und enthalten leider Informationen, die nirgendwo anders stehen.

In Small guide to using VB6 with TFS 2012 habe ich einen netten Guide für TFS gefunden, allerdings nichts über Branches. Im TFS Branching Guide steht leider auch nichts dazu.

Vom TFS gibts auch eine lokale und kostenlose Express-Variante, die etwas eingeschränkt ist (nur SQL Server Express, keine SharePoint- oder Reportintegration, nur 5 Benutzer...). Nutze ich bisher, werde aber in Kürze auf die größere Version umsteigen. Allerdings habe ich das beschriebene Problem nicht mit binären Dateien - und ich verstehe es auch nicht so recht. Irgendwo müssen diese binären Dateien ja generiert werden, und zwar aus lesbaren Dateien. Und nur diese gehören in die Versionsverwaltung.

Die frx Dateien werden aus den frm Dateien erzeugt und gehören definitiv nicht in ein VCS.

Was genau willst du zum TFS Branching wissen?

Ehrlich gesagt hab ich das Gefühl, dass ihr selbst SourceSafe bis jetzt "falsch" genutzt habt, und ihr jetzt versucht den falschen Weg fortzusetzen.

Hi.

Falls du dich bei git nicht mit der Kommandozeile rumschlagen willst (was ich aber jedem empfehlen würde), dann kannst du auch git extensions benutzen. Es handelt sich um eine sehr gute grafische Oberfläche und die Visual Studio Integration ist gleich mit dabei.

MfG
wax

Im Grund will ich blos sagen, ich würde die entscheidung ev. nicht zu sehr von VB6 abhängig machen.