Subversion und VisualSVN für Ein-Mann-Entwicklung

[Phoenix]

Zitat von haentschman:

Moin...

Naaahmd

Zitat von haentschman:

Ich liebe es das ganze über eine altbekannte Struktur benutzen zu können...ohne irgendwelche Konsolenbefehle.

Dann nimmt man (kostenlose) GUI-Tools wie GitKraken, SourceTree, oder TortoiseGit (wobei mir das zu SVN-Lastig ist).

Zitat von haentschman:

Auch wenn der Server "nicht online" ist kann ich kann ich weiterarbeiten. Beim nächsten "online" wird halt eingecheckt. Das Argument greift bei mir nicht.

Das ist das schöne an Git. Du kannst ein Repo komplett lokal, komplett ohne Server betreiben - wenn Du das magst.
Oder Du hast einen zentralen Server (SVN-Like) - wobei Du eben auch weiter arbeiten kannst wenn der Server nicht erreichbar ist.

Zitat von haentschman:

PS: Ich habe mich noch nicht wirklich damit beschäftigt...z.b. ich weiß nicht wo die Daten (QT) liegen. Ein eigener Server im lokalen Netz (von außen erreichbar) ist mir lieber.

Auch das kannst Du haben

[warschonweg]

Ich spiele mal Avocado Diablo oder so:

Alle Vorteile von Git hast du mit Mercurial (unterstützt u.a. von TortoiseHg und SourceTree) auch - und zusätzlich ein wesentlich stabileres, weniger fehleranfälliges Branching.
"Industriestandard", "Verbreitung" usw.usf. können dir (wie mir) für private Projekte herzlich schnuppe sein, allerdings setzen Mercurial zum Beispiel Mozilla und Firefox ein.

Ich persönlich speichere das Gros meiner Projekte übrigens einfach in der Dropbox. Die macht mir auch Dateirevisionen.

edit, gerade gesehen: Danach hattest du ja schon oben gefragt. Also: Hier, klarer Fürsprecher!

[jaenicke]

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...

Zitat von Jim Carrey:

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

Ich zitiere mich mal selbst von hier:

Zitat von jaenicke:

Und wie ich an anderer Stelle schon einmal geschrieben habe gibt es ja noch einige andere Vorteile, die man auch als Einzelperson hat:

• Du siehst welche Änderungen du gemacht hast, wenn z.B. plötzlich etwas nicht mehr funktioniert
• Du siehst beim Abschicken der Änderungen, ob du unbeabsichtigte Änderungen drin hast (z.B. Debugausgaben, ...)
• Du hast alle Dateien an genau einer definierten Stelle und brauchst nicht (wie es leider viele ohne Versionsverwaltung machen) Kopien anlegen, die dann evtl. aus Versehen benutzt werden usw.
  Kopien, bei denen man dann wiederum nicht weiß was da eigentlich mittlerweile geändert wurde. Dann kehrt man zu einer Version zurück, nur um zu bemerken, dass eine andere Änderung weg ist, ...
• Du kannst mehrere Entwicklungen parallel machen, zwischen beiden hin- und herschalten und am Ende beide zusammenführen
• Du kannst einfach zu einer älteren Version zurückgehen und testen, ob ein Fehler dort schon drin war oder ob etwas dort anders funktioniert hat
• Du kannst jederzeit im Quelltext etwas komplett ändern oder auch löschen um z.B. einen Fehler zu finden, da du die Version ja jederzeit wiederherstellen kannst

[Jim Carrey]

Zitat:

Du siehst welche Änderungen du gemacht hast, wenn z.B. plötzlich etwas nicht mehr funktioniert

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.

Zitat:

Du siehst beim Abschicken der Änderungen, ob du unbeabsichtigte Änderungen drin hast (z.B. Debugausgaben, ...)

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

Zitat:

Du hast alle Dateien an genau einer definierten Stelle und brauchst nicht (wie es leider viele ohne Versionsverwaltung machen) Kopien anlegen, die dann evtl. aus Versehen benutzt werden usw.

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

Zitat:

Kopien, bei denen man dann wiederum nicht weiß was da eigentlich mittlerweile geändert wurde. Dann kehrt man zu einer Version zurück, nur um zu bemerken, dass eine andere Änderung weg ist, ...

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

Zitat:

Du kannst mehrere Entwicklungen parallel machen, zwischen beiden hin- und herschalten und am Ende beide zusammenführen
Du kannst einfach zu einer älteren Version zurückgehen und testen, ob ein Fehler dort schon drin war oder ob etwas dort anders funktioniert hat
Du kannst jederzeit im Quelltext etwas komplett ändern oder auch löschen um z.B. einen Fehler zu finden, da du die Version ja jederzeit wiederherstellen kannst

Das sind wenigstens drei nützliche Funktionen. Der Rest oben ist einfach Mumpitz wie ich finde.

[jaenicke]

Zitat von mse1:

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 von Jim Carrey:

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 von Jim Carrey:

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 von Jim Carrey:

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

Das Argument passt bei dir nicht, nein.

Zitat von Jim Carrey:

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.

[mse1]

Zitat von jaenicke:

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]

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

[Harry Stahl]

Zitat von jaenicke:

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.

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 von Harry Stahl:

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.

[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.