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.

Ich hab mal wo gelesen, dass man VB6 mit einem Batch/Update den TFS hinterlegen kann (anstatt von SourceSafe).
Google mal danach (find leider den Link nicht mehr). Aber möglich ist es soweit ich weiß.

lg

Ich habe den TFS ausprobiert. Es gibt da eine ziemlich gute Import-Funktion. Das ist auch, wie gesagt, nicht das Problem. Das Branchen ist das Problem.

Was genau ist dieses "Branchen"? Hab das noch nie gehört

lg

Einen oder mehrere Entwicklungszweige erstellen.

Ah Danke sehr!

So "Branches" hört sich für mich irgendwie riskant an. Funktioniert sowas in der Praxis wirklich?

lg

Ja, das ist sogar sehr wichtig.
Der normale Entwicklungsvorgang geht ja so, dass man so lange entwickelt, bis man aus dem Ergebnis ein Release macht. Dieser Entwicklungsstand wird "eingefroren" (nennt man dann meistens Trunk) mit der Version 1.0.0. Daraus wird dann ein Branch erstellt, auf dem man für Version 2.0.0 entwickelt. In der Zwischenzeit arbeiten Kunden mit Version 1.0.0 und finden kritische Bugs. Diese werden in beiden Zweigen (Trunk und Branch) behoben. Aus Trunk wird dann z.B. 1.0.1 erstellt und ausgeliefert. 1.0.1 enthält natürlich noch nicht die neuen und ungetesteten Funktion, die für Version 2.0.0 entwickelt wurden, weil diese ja in einem anderen Zweig sind.

GambaJo schrieb:

Diese werden in beiden Zweigen (Trunk und Branch) behoben

Muss man in diesem Fall den Code dann doppelt schreiben oder?
Und das kann SourceSafe bereits? EDIT: gerade gelesen im Post 1, dass ers NICHT kann

lg

Wenn ihr schon einen Windows Server habt (nehme ich an), warum nehmt ihr dann nicht Git?
Seit VS2013 ist ein Modul für Git direkt eingebaut. Für VS6 müsstet ihr TortoiseGit oder GitHub for Windows (mit privater Repository -> kein GitHub erforderlich) nehmen.

"Dateien manuell zu kopieren" -> Rechtsklick in TortoiseGit, Create Branch. Dann wird alles für dich erledigt. Manuell Dateien kopieren ist nicht nötig.

Ich werde Git mit einem erfahrenen Nutzer nächste Woche ausprobieren. TFS wäre aber meine erste Wahl.

Wäre toll, wenn du dann einen Erfahrungsbericht posten könntest, da mich das ganze auch intressiert

lg

Hab mit Git jetzt schon recht viel Erfahrung gesammelt und kann es nur empfehlen. Hat nie Probleme gemacht, läuft stabil und ist wenn man es erstmal raus hat auch recht simpel. TFS kann ich eigentlich nur das Selbe sagen. Für .NET Sachen verwende ich meistens TFS(bis auf Ausnahmen wie z.B. CSCore) für andere Dinge aber auch manchmal Git.

Ein großer Vorteil von Git ist IMO, dass es möglich ist, komplett ohne Server ein Repository anzulegen. Außerdem ist es recht Portabel - ein Git-Repo kann einfahc auf einen USB-Stik gezogen oder auf einem komplett anderem Betriebssystem weiterverwendet werden, ohne, dass etwas umkonfiguriert werden muss.

AliveDevil schrieb:

Für VS6 müsstet ihr TortoiseGit oder GitHub for Windows (mit privater Repository -> kein GitHub erforderlich) nehmen.

TortoiseGit ist... Müll. GitHub for Windows ist, wie der Name schon vermuten lässt, speziell auf GitHub ausgelegt, auch wenn die Verwaltung normaler Repos möglich zu sein scheint.
Ich denke ich lehne mich nicht weit aus dem Fenster, wenn ich sage, dass der beste Git-Client für Windows msysgit ist (zumal es auch der "offizielle" Client ist). Die Git-Shell macht einfach mehr her.

Branching funktioniert mit Git (nur da habe ich das bereits so exzessiv genutzt) einwandfrei. Ich habe teileweise auch schon 4 Branches mit recht großen Änderungen gleich nacheinander gemerged - ohne Probleme. Falls Git merkt, dass es ein Problem geben könnte, überlässt es die Migration dem Benutzer. Dies ist meistens nur der Fall, wenn sich die Änderungen der 2 Branches überschneiden. Und selbst wenn es mal fehlschlagen sollte, kann man jede Änderung immer rückgängig machen (kaum zu glauben, aber bei einem VCS ist das möglich! :)).
Da Git schließlich für den Linux-Kernel entwickelt wurde, kann man sich auch darauf verlassen, dass es funktioniert.

Ich wüsste keinen Grund, warum Git nicht mit VB6 funktionieren sollte. Man sollte sich nur über den Einsatzzweck im Klaren sein und ggf. evaluieren, ob ein zentrales System (TFS, Git) nicht doch angebrachter ist.

nikeee13 schrieb:

Ich wüsste keinen Grund, warum Git nicht mit VB6 funktionieren sollte.

Ich leider schon. Forms bestehen in VB6 aus zwei Dateien, die von der IDE generiert werden. leider handelt es sich bei der einen Datei um eine Binär-Datei. Die Informationen darin sind leider nicht komplett an anderer Stelle verfügbar. Und binäre Dateien mergen ist unmöglich.
Oder hast Du explizit persönliche Erfahrung mit VB6-Forms und Git?

Wenn das wirklich so ist, dann ist das echt suboptimal. Ich wusste nicht, dass VB6 da binär arbeitet. Dann ist, so denke ich, ein zentrales VCS mit expliziten Datei-Checkouts/Checkins doch angebrachter. Merging wird dann aber auch dort ein Problem.

So sehe ich das auch.
So weit ich weiß, kann man in SVN Regeln anlegen, dass man diese Dateien dann doch exklusiv öffnen muss.

nikeee13 schrieb:

Ich wusste nicht, dass VB6 da binär arbeitet.

Das passiert in VB6 immer (nur) dann, wenn man in den Controls einer Form die entsprechenden Eigenschaften mit (binären) Daten vorbelegt, z.B. wenn man im Form-Designer einem Picture-Steuerelement direkt eine Bitmap zuweist oder in der Form selbst die Icon-Eigenschaft festlegt.
Daraus resultieren dann neben den Text-FRM-Dateien parallel die .FRX-Dateien in denen diese Daten als eine Art "zum Formular gehörende Resourcen" binär gespeichert werden.