Subversion und VisualSVN für Ein-Mann-Entwicklung

[Harry Stahl]

Zitat von haentschman:

Ein eigener Server im lokalen Netz (von außen erreichbar) ist mir lieber.

Hast Du dafür einen EXTRA-PC als Server eingerichtet, wo dann auch der SVN-Server läuft (welchen nutzt Du?) oder ist es Dein Entwicklungs-PC, den Du dann von außen erreichen kannst (per Port-Weiterleitung)?

Ist das dann noch performant genug? Gerade auch, wenn es um Upload geht, sind die Webserver doch i.d.R. um einiges schneller.

Mein "Super-Duper" Telekom-Internet verabschiedet sich hin und wieder auch mal (alle 1-3 Wochen), so dass der Router neu gestartet werden muss, wäre doof, wenn ich da gerade unterwegs bin.

[Jim Carrey]

Zitat:

Ich habe beides mal versucht, aber bin damit nicht klar gekommen - und lieber bei Sicherungen in Zips (auch eigene Lösung) geblieben.

Ein Mensch meiner Gattung

Warum immer so super kompliziert und erst diesen Kram lernen, wenn ZIP-Backups viel, finde ich, sicherer sind?

[stahli]

@Jim

Wobei ich darauf weniger Stolz bin als Du.
Aber wenn ich mit dem Tretroller besser vorwärts komme als mit einem Auto, weil das zu viele Schalter hat, dann eben mit Tretroller...

(Wenn ich in einem Team arbeiten und angelernt würde, ginge es sicher. So allein hatte ich noch keine Motivation, mich da rein zu beißen.)

[Jim Carrey]

Wenn man alleine arbeitet lohnt sich Git und all der Kram meiner Meinung nach nicht.
Wenn man einen Bug verursacht, weiß man in der Regel genau wo. Da brauche ich keine Versionskontrolle, um den Bug später finden zu können.

Daher meine Theorie:
sind Versionskontrollsysteme in Wahrscheit für Menschen, die ihren Code nicht kennen?

[haentschman]

Zitat:

wenn ZIP-Backups viel, finde ich, sicherer sind?

...das bezweifle ich. Die Übersicht zu behalten und z.b. einzelne Dateien aus der Sicherung wiederzustellen halte für nicht SICHER.

[ThomasBab]

Hallo!

Seinerzeit habe ich auch mit zip/arj-Archiven hantiert. Aber es ist immer schlecht, wenn man Unterschiede in einzelnen Versionen ermitteln will.

Dann kam svn: damit habe ich einige Jahre gearbeitet (auch mit graphischer Oberfläche). Das fand ich schon sehr angenehm und es vermittelt auch ein gewisses Maß an Sicherheit, wenn man jederzeit auf einen älteren Stand zurückschauen/zurückgehen kann.

Als ich dann - aus welchen Gründen auch immer - zu git gewechselt bin, habe ich mich sehr schnell von der graphischen Oberfläche von git verabschiedet und nutze es jetzt ausschließlich über die Kommandozeile. Damit bin ich viel schneller und zielführender.

Es ist klar, dass die Einarbeitung in git etwas aufwendig ist, aber es lohnt sich.

Hier ein paar auf die Schnelle gefundene Links zur Einführung in git:
https://www.atlassian.com/git/tutorials/

https://rogerdudler.github.io/git-guide/

https://www.tutorialspoint.com/git/

https://www.ralfebert.de/tutorials/git/

Und wenn man bei git eingestiegen ist, lohnt es sich, mal nach "git flow" zu schauen.

Ich bin auch nur ein Einzelkämpfer, aber ich arbeite mit unterschiedlichen PC. Dort ist es sehr schön, wenn man mal an einem PC "irgendwas testen" kann, ohne dass man Angst haben muß, ein Durcheinander anzurichten.

Außerdem hat git gegenüber svn den Vorteil, dass man das gesamte repository "immer dabei hat". Das war für mich der Grund, von svn auf git zu wechseln.

Gruß
thomas

[Harry Stahl]

Zitat von ThomasBab:

Ich bin auch nur ein Einzelkämpfer, aber ich arbeite mit unterschiedlichen PC. Dort ist es sehr schön, wenn man mal an einem PC "irgendwas testen" kann, ohne dass man Angst haben muß, ein Durcheinander anzurichten.

Ja, genau, das ist auch bei mir so ein Grund. Ich entwickle ja einige Client-Server-Programme und da ist es gut, wenn man das für das Server-Programm tatsächlich auf einen anderen PC macht, als den, wo ich das Client-Programm entwickle (es gibt auch gewisse Limits an den Virtuellen Maschinen, manchmal braucht man wirklich eine echte).

Aber auf diesem 2. PC habe ich dann auch meine Shared Units, die sich dann schon mal abweichend von den Shared-Units auf dem 1. PC entwickelt haben. So etwas hoffe ich mit einer SVN-Verwaltung zu vermeiden, bzw. wenn man eine shared Unit "aktualisiert" und damit aber Änderungen versehentlich verwirft, noch mal leicht auf den vorherigen Stand zurück zu kommen.

Natürlich verwende ich hier bislang ein mehrstufiges Backup-System (intern und extern), aber da muss man u.U. auch erst mal lange suchen, wo dann das Backup ist, welches die Datei xyz.pas zu einem bestimmten Zeitpunkt enthielt.

[haentschman]

1. alle Dateien befinden auch ausgecheckt auf dem Computer womit du arbeitest.
2. du änderst den QT einer gemeinsamen Unit.
3. am Original ändert sich nix
4. wenn du lokal die Änderungen rückgängig machen willst musst du auf den Server zugreifen.
5. ! die gemeinsamen Units liegen in einem gemeinsamen Ortner und nicht als Kopie im Project Ordner?

...wo ist das Problem?

Was hat die Entwicklungsumgebung mit dem VCS zutun? Ich benutze SVN über meinen bevorzugten Dateimanager. (Speedcommander)

[Harry Stahl]

Zitat von haentschman:

1. alle Dateien befinden auch ausgecheckt auf dem Computer womit du arbeitest.
2. du änderst den QT einer gemeinsamen Unit.
3. am Original ändert sich nix
4. wenn du lokal die Änderungen rückgängig machen willst musst du auf den Server zugreifen.
5. ! die gemeinsamen Units liegen in einem gemeinsamen Ortner und nicht als Kopie im Project Ordner?

...wo ist das Problem?

Ja, die gemeinsamen Units liegen in einem gemeinsamen Ordner (auf den auch andere Projekte zugreifen) und NICHT als Kopie im Projekt Ordner.

[Harry Stahl]

Also, ich werde jetzt gerade noch etwas mit Subversion weitertesten, um überhaupt mal so einen Eindruck zu bekommen, was machbar ist, wie das Handling so ist, usw.

Folgende Situation:

Habe ein Verzeichnis "AServer", welches Unterverzeichnisse "Prog" und "Service" enthalten.

Im Verzeichnis "AServer" liegt eine ProjektGruppendatei, welche Projekt.dproj-Dateien aus den Ordnern "Prog" und "Service" enthalten.

In den beiden Einzelprojekt-Dateien sind units drin, die in beiden Projekten (PRog und Service) vorkommen.

Wenn ich jetzt die Projektgruppendatei mit den 2 enthaltenen Einzelprojekten in die Repository laden will, werden in der Liste "Zu übergebende Dateien" einzelne Dateien doppelt aufgelistet (da ja Dateien sowohl im Projekt "Prog" und "Service" vorkommen. Beim anschließenden Versuch per Klick auf den Schalter "Importieren" kommt der Hinweis "Datei xzy" ist bereits unter Versionskontrolle.

Ist das nicht mit Subversion hinzubekommen? Aber mit GIT?. Das wäre dann ein Argument.