Subversion: ja/nein bei folgender Anforderung

[hoika]

Hallo,

#Alles auf einen Haufen werfen#
?

Was meinst du damit?

[dGeek]

Sobald ich mir bei der Benutzung einer Software mehr als N Fragen stellen muss ist für mich klar, dass ich diese nicht verwende.
Ich persönlich halte von SVN und Git absolut nichts. Das ist alles nur verlorene Zeit für nicht und wieder nichts.

Ich mache meine Backups alle automatisiert in ZIP-Dateien! Alles immer auf einmal.
Und wenn ich meine Codes vergleichen möchte, gibt es noch immer BeyondCompare. Ein super Programm!

[Neutral General]

Zitat von dGeek:

Sobald ich mir bei der Benutzung einer Software mehr als N Fragen stellen muss ist für mich klar, dass ich diese nicht verwende.
Ich persönlich halte von SVN und Git absolut nichts. Das ist alles nur verlorene Zeit für nicht und wieder nichts.

Das würde ich so nicht sagen. Aber so kompliziert und umständlich wie hier geredet wird benutze ich SVN auch nicht.
Nichtmal auf meiner ehemaligen Arbeitsstelle mit ca. 10 Programmierern haben wir so einen Aufstand gemacht. Jeder hat an etwas programmiert und wenn er fertig war hat er es eingecheckt.
Das geht zu 99,9% ohne Probleme. In 0,1% muss man dann vllt. auch mal etwas von Hand mergen.

[hoika]

Hallo

#Jeder hat an etwas programmiert und wenn er fertig war hat er es eingecheckt.#

Und was ist, wenn er an Unit1 arbeitet (noch nicht eingecheckt).
Jetzt wird ein Bug in ebend dieser Unit1 gefunden, von ihm behoben und ...

einchecken: nicht fertige Sachen werden mit eingecheckt
nicht einchecken: Bug kommt nicht ins Release

Er könnte jetzt:
- seine Unit1 mit den lokalen Änderungen retten
- Update to Revision X
- Bug beheben
- Commit (in Branch oder Trunk, was auch immer)
- gerettete Unit1 zurück
- Update, damit auch Merge mit dem Committed Bug

Also wenn da nicht Fehler vorprogrammiert sind ...

Das kommt bei uns leider öfters vor.

Das mit dem Zippen geht nicht, wir sind auch mehrere Entwickler.
Das mit dem einfachen Beispiel war ebend wegen der Einfachheit des Erklärens.

[CarlAshnikov]

Bei Tortoise SVN gibt es "restore after commit", das stellt die ursprüngliche Version einer Datei nach dem Committen wieder her indem es eine temporäre Kopie erzeugt.
Damit ist es möglich nur eine Änderung einer Datei zu committen ohne eine zweite Änderung zu verlieren oder sie vorher retten zu müssen.

[Der schöne Günther]

Das wollte ich grade sagen. Du kannst doch nur einen Teil der Datei committen, niemand zwingt dich die ganze Datei zu nehmen. Hat Subversion nicht mittlerweile auch so etwas was git "stash" (oder Mercurial "shelve") nennt? Damit kannst du Changesets nehmen und sie beiseite legen.

[jaenicke]

Gerade für viele "hängende" Features würde ich lieber Git nehmen. Bei Git sind Branches keine Last wie bei SVN (wo da relativ viel kopiert wird usw.), sondern können jederzeit ohne Probleme erstellt und wieder gemerged werden.
Dazu kommt, dass direkt im Sync-Dialog das Stash Save und Stash Apply drin ist um eigene Änderungen zwischenzuspeichern und später wieder einzuspielen.

Zitat von dGeek:

Sobald ich mir bei der Benutzung einer Software mehr als N Fragen stellen muss ist für mich klar, dass ich diese nicht verwende.
Ich persönlich halte von SVN und Git absolut nichts. Das ist alles nur verlorene Zeit für nicht und wieder nichts.

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

Zitat von jaenicke:

• 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