Subversion und VisualSVN für Ein-Mann-Entwicklung

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