Subversion und VisualSVN für Ein-Mann-Entwicklung

[mse1]

Ich habe nicht den ganzen Thread gelesen, bin aber platt, dass es möglich sein soll ohne Versionskontrolle professionell Software zu entwickeln. Meiner Meinung nach ist auch für das kleinste Hobbyprojekt die Verwendung von Git oder einem anderen tauglichen VCS eine grosse Erleichterung. SVN ist eher nicht tauglich IMHO...
Für Git gibt es das in Free Pascal geschriebene MSEgit Frontend. Das habe ich gemacht, um ein Werkzeug zu erhalten, welches für meine Aufgaben das Maximum an Produktivität und Bequemlichkeit bietet und da alle erhältlichen GUIs meine Wünsche nicht befriedigen konnten.
Ein geändertes Projekt sieht dann z.B. aus wie "modified.png". Mit 'git'-'Commit/Stage/Unstage all (Ctrl+O)' kann der Projektstand in einem Schnappschuss festgehalten werden ("commit.png").
Jeder Projektzustand erhält einen zugeordneten Hashwert (SHA,Quersumme), welche zusammen mit dem Hashwert des Vorgängerzustandes abgelegt wird. Im Beispiel ist der SHA f9870430c6b809667e418748a2c9b1f13828651c, der des Vorgängers ('Parent') 94d840349de35a917a2688865614781a8fdf3cd4 ("committed.png"), dabei kann man die Änderungen nochmals in aller Ruhe überprüfen.
Die gesamte Kette der Projektzustände ist im Projektverzeichnis im Unterverzeichnis ".git" abgelegt; es kann jeder beliebige Zustand aus dem ".git" in das Projektverzeichnis zurückgeholt werden.
Wenn man also z.B. den Verdacht hat, mit der letzten Änderung einen Bock geschossen zu haben, kann man durch Auswählen einer Zeile im Log und RightClick-'Checkout' ein früherer Zustand zurückholen.
Zustände können Namen erhalten. Eine Zusammenhängende Zustandskette mit Namen nennt man Branch. Es gibt Möglichkeiten um Änderungen von einer Branch in andere Branch zu Übertragen.
Zustände können auch in andere git Repositories übertragen werden (push) oder von anderen Repositories ins Projekt-git-Archiv geholt werden (fetch). Die grünen Pfeile in "committed.pdf" bezeichnen Dateien, welche noch nicht in das Aktuelle remote-git-Repository übertragen wurden.
Viele meiner Projekte sind in GitLab öffentlich gemacht:
https://gitlab.com/groups/mseide-msegui
Für interne Projekte verwende ich als Backup und Netzwerk Repository Gitolite
http://gitolite.com/gitolite/index.html
MSEgit gibt es hier:
https://sourceforge.net/projects/mse.../files/msegit/
das Projekt ist hier:
https://gitlab.com/mseide-msegui/mse...r/tools/msegit

[jaenicke]

Zitat:

Zitat von mse1 (Beitrag 1352748)

Ein geändertes Projekt sieht dann z.B. aus wie "modified.png". Mit 'git'-'Commit/Stage/Unstage all (Ctrl+O)' kann der Projektstand in einem Schnappschuss festgehalten werden ("commit.png").

Die Ansichten finde ich total unübersichtlich. Dass man bei solchen Fenstern als VCS-Einsteiger keine Lust mehr hat, kann ich absolut nachvollziehen. Da habe ich selbst ja auch schon keine Lust mehr mir das anzuschauen. ;-)

Da finde ich die Fenster und Ansichten aus meinen Screenshots mit TortoiseGit deutlich besser:
http://www.entwickler-ecke.de/topic_...it_115462.html

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Finde ich sehr Schwach dieses Argument. Wenn etwas plötzlich nicht mehr funktioniert, weiß man in der Regel wo man kürzlich dran gearbeitet hat.

Das hilft dir aber auch nur bedingt, wenn du nicht einfach die thematischen einzelnen Änderungen durchgehen kannst, sondern lediglich mehrere Versionsstände auf Dateiebene miteinander vergleichen kannst.
Natürlich kann man auch so vergleichen, es ist aber ein Vielfaches umständlicher.

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Auch das sollte einem normalerweise nicht passieren und ist mir in mittlerweile 9 Jahren nicht passiert.

Zumindest hast du es nicht bemerkt. Da du beim Abschicken der Änderungen keine Prüfung durchführst, kannst du es ja gar nicht merken, außer wenn du irgendwann merkst, dass etwas nicht mehr geht. Da du die letzten Änderungen an der Stelle aber auch wiederum dann später gar nicht zur Verfügung hast, kannst du auch wiederum nicht so einfach feststellen, dass das Problem bei einer bestimmten Änderung eingebaut wurde.

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Meine ZIP-Archive sind auch an einer definierten Stelle =)

Das Argument passt bei dir nicht, nein.

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Ebenfalls ein schwaches Argument wie ich finde. Man sollte seinen Code schon kennen.

Das kommt eben auf die Projektgröße an. Weder bei meinen beruflichen noch bei meinen privaten Projekten kann ich den Code auswendig kennen, weil der Quelltext schlicht zu umfangreich ist. Und schon gar nicht Jahre später noch wissen was wie läuft.

[Harry Stahl]

Zitat:

Zitat von jaenicke (Beitrag 1352744)

Ich habe hier zu Git mal eine kurze Einführung mit Screenshots geschrieben (wirklich nur kurz zum Einstieg):
http://www.entwickler-ecke.de/topic_...it_115462.html
Zum Server bin ich leider noch nicht gekommen...

Danke, das ist sehr hilfreich.:thumb:

Auch Dein Tutorial zu Subversion hätte mir eine Menge Raterei erspart, wenn ich es schon gekannt hätte...

In Fakt sieht es aber so aus, als ob alle Leute, die Versionsverwaltung machen, NICHT die Integration in Delphi verwenden, um die Änderungen zu posten oder zu holen, oder sehe ich das falsch?

[mse1]

Zitat:

Zitat von jaenicke (Beitrag 1352749)

Die Ansichten finde ich total unübersichtlich.

Selbstverständlich kann man sich bei MSEgit die Fenster einrichten wie man will. Wie hättest du es denn gerne?

[mse1]

Zitat:

Zitat von Harry Stahl (Beitrag 1352750)

In Fakt sieht es aber so aus, als ob alle Leute, die Versionsverwaltung machen, NICHT die Integration in Delphi verwenden, um die Änderungen zu posten oder zu holen, oder sehe ich das falsch?

Ich finde die Integration alles und jedes in eine IDE keine gute Idee. Dadurch entsteht ein unhandliches fehleranfälliges Monster das so kompliziert zu programmieren ist, dass man bei der Qualität, Funktionsumfang und Usability zwangsläufig Abstriche machen muss.

[Harry Stahl]

Doppelter Post (gelöscht)

[Frickler]

Ich nutze jetzt seit ca. 10 Jahren Subversion in Form von TortoiseSVN. Davor habe ich ZIP-Archive gemacht. Was ich als riesigen Vorteil gegenüber den ZIP-Archiven sehen, ist, dass ich beim Einchecken von Änderungen einen Kommentar hinterlegen kann (z.B. sowas wie "Anforderung #4711 - Schriftart in den Buttons fett" oder so). So kann ich auch noch Jahre später sehen, was gemacht wurde, ohne jedesmal in die Diffs sehen zu müssen.

Meine Struktur ist so: jede Projektgruppe ein Archiv, und zusätzlich ein Archiv für einen "LIB"-Ordner, in dem gemeinsame Bibliotheken liegen. Jede Projektgruppe besteht aus einzelnen Ordnern für die Unterprojekte, und auch dort einem "LIB"-Ordner für alles, was für alle jeweiligen Unterprojekte gemeinsam benötigt wird (z.B. auch fr3-Reportdateien).

Die ganze Entwicklung läuft auf 2 peer-to-peer vernetzten Rechnern, ein Server und ein "VM-Server" mit VMs für jede Entwicklungsumgebung und für jeden Testrechner.

[Jim Carrey]

Zitat:

Natürlich kann man auch so vergleichen, es ist aber ein Vielfaches umständlicher.

Da ist garantiert was dran und das bestreite ich nicht.

Zitat:

Das kommt eben auf die Projektgröße an. Weder bei meinen beruflichen noch bei meinen privaten Projekten kann ich den Code auswendig kennen, weil der Quelltext schlicht zu umfangreich ist. Und schon gar nicht Jahre später noch wissen was wie läuft.

Mein aktuelles Projekt hat derzeit ohne Leerzeilen 56.000 Zeilen.
Das ist nicht sonderlich viel aber ich weiß immer ganz genau was ich wo finde.

Zitat:

Was ich als riesigen Vorteil gegenüber den ZIP-Archiven sehen, ist, dass ich beim Einchecken von Änderungen einen Kommentar hinterlegen kann (z.B. sowas wie "Anforderung #4711 - Schriftart in den Buttons fett" oder so). So kann ich auch noch Jahre später sehen, was gemacht wurde, ohne jedesmal in die Diffs sehen zu müssen.

ZIP-Archive können auch Kommentare enthalten.

[Valle]

Werden noch Leute für die Statistik benötigt? :stupid:

Ich lege ebenso für jedes Projekt, bei dem ich davon ausgehe dass ich es morgen nochmal anfassen werde, ein Git Repository an. Ein paar veröffentliche ich auch auf Github. Mit SVN braucht man heute nicht mehr anfangen. Ich würde empfehlen sich für Git (oder gern auch Mercurial) mal ein paar Tage lang mit der Konsole zu befassen. Wenn einem die Konsole dann immernoch nicht zusagt, kann man ja wechseln. Ich bin mit der Konsole ein vielfaches schneller und verstehe auch besser was Git da tut.

Mit Zip-Dateien entwickeln... kann man machen. ( :zwinker: ) Aber falls mal jemand mit Versionierung überhaupt erst anfängt, würde ich empfehlen einfach eine fertige Lösung für das Jahrzehnte alte Problem zu verwenden und sich in Git einzuarbeiten. Solange man das nicht einfach "schon immer so macht", sehe ich in Zips keine weiteren Vorteile.

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1352750)

In Fakt sieht es aber so aus, als ob alle Leute, die Versionsverwaltung machen, NICHT die Integration in Delphi verwenden, um die Änderungen zu posten oder zu holen, oder sehe ich das falsch?

Das haben wir versucht, eigentlich wäre die sehr praktisch. Neue Units automatisch ins Repository usw., an jeder Zeile die letzte Änderung sehen, ...

Wenn das alles geklappt hätte, hätten wir auch einen eigenen Commit-Dialog gebaut, der die für uns nötigen Angaben (Ticketnummer usw.) direkt in das passende Format bringt, damit unsere Build Tools diese extrahieren können.

Aber leider gab es immer wieder mal Schutzverletzungen, nach denen wir dann manuell Cleanups machen mussten. Deshalb haben wir es am Ende aufgegeben...

Wir benutzen jetzt TortoiseSVN und TortoiseGit mit einem externen Tool um den Committext zu erstellen. Den kopieren wir dann einfach hinein.