Subversion: ja/nein bei folgender Anforderung

[hoika]

Hallo,
für ein kleines Projekt habe ich ein SVN-Repository aufgesetzt,
soweit so gut.

Projekt1.dpr
Unit1.pas
Unit2.pas
Unit3.pas

Ich arbeite in Unit2 schon mal an 2 Features und checke das auch ein.
Halt!
Vorher wird ein Branch dafür angelegt.
Ich will ja, dass ich die aktuelle Version (Trunk) immer auch an einem anderen Rechner auschecken kann.

Feature 1 ist fertig, Feature 2 noch nicht.
Jetzt soll Feature 1 in den Trunk gemerged werden.
Das Mergen klappt doch aber nur über Revisions (?).
In der letzten Revision sind aber auch die unvollständigen Teile von Feature 2 drin.

Wie bekomme ich das jetzt hin, nur Feature 1 zu mergen?

So richtig verstehe ich das Subversion hier nicht.
Muss ich da 2 Branches nehmen?
Wenn ich 10 Features parallel entwickle, muss ich da 10 Branches nehmen,
falls ich die einzeln später in die Release-Version reinhaben will?

Das SVN-RedBook zeigt ja immer nur den Idealfall (alles im Branch wird gemerged).

[Der schöne Günther]

Mit Subversion verlassen mich langsam die Erinnerungen, aber das Redbook scheint da eigentlich doch konkret zu antworten auf deine Frage "Muss ich da 2 Branches nehmen?":

Zitat:

Most projects take a middle-of-the-road approach. They commonly insist that /trunk compile and pass regression tests at all times. A feature branch is required only when a change requires a large number of destabilizing commits. A good rule of thumb is to ask this question: if the developer worked for days in isolation and then committed the large change all at once (so that /trunk were never destabilized), would it be too large a change to review? If the answer to that question is “yes,” the change should be developed on a feature branch. As the developer commits incremental changes to the branch, they can be easily reviewed by peers.

Quelle: http://svnbook.red-bean.com/en/1.7/s...npatterns.html

[Bbommel]

Also, ich bin letztlich auch nur relativ einfacher Benutzer von SVN über TurtoiseSVN und kenne sicherlich nicht alle ganz fiesen Tricks, die irgendwo verborgen sind, aber so, wie du beschreibst, was du machst: ja, wenn du parallel an 10 neuen Features arbeitest, von denen die anderen noch halbfertig sind (und damit den Trunk instabil machen, siehe Günthers Anmerkung), dann bräuchtest du 10 Branches.

Wenn du das vermeiden willst, dann müsste zumindest die Änderung in einem Commit sauber sein und sich nur auf eines deiner Features beziehen, dann könntest du einzelne Revisions zurück in den Stamm mergen und damit ein neues Feature einführen. Wenn aber in einem einzelnen Commit die Änderungen sind, die ein Feature fertigstellen, zugleich aber ein anderes Feature halb anfangen, dann wird es schwierig. Eine Möglichkeit, sozusagen nur halbe Revisions zurückzumergen, habe ich bisher noch nicht gefunden (aber auch nicht gesucht ;) ).

[hoika]

Hallo,
#Günther'
oha, habe ich wohl doch überlesen.

Peer Review, ja das wollte ich vermeiden.

Ich habe hier stellenweise Änderungen von vor 2 Jahren, die immer noch im Code schlummern,
aber nicht released werden, weil ich sie noch nicht komplett testen konnte.

Aber bei dem vorgeschlagenen Weg, nur dann Branches zu machen, wenn jemand lange isoliert an Features arbeitet,
brauche ich ja gar kein Branches ;)

#Bbommel#:
Ja, habe ich auch nicht gefunden.


Ein Beispiel:
Unit 2
Feature 1.0: Farbe im Grid ist blau.
Feature 1.1: Farbe im Grid wird anhand anderer Werte berechnet
Faeture 2 : Grid enthält zusätzliche Daten

Jetzt will ich Feature 1.1 aktivieren, Feature 2 ist aber ungetestet
und soll deshalb noch nicht aktiviert werden.

[Der schöne Günther]

Alles auf einen Haufen werfen hört sich aber nicht gut an :oops:

Ich frage mal anders herum: Was spricht eigentlich dagegen?

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

Zitat von dGeek (Beitrag 1345593)

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:

Zitat von dGeek (Beitrag 1345593)

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:

Zitat von jaenicke (Beitrag 1342479)

• 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

[dGeek]

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

[Benedikt Magnus]

Zitat:

Zitat von dGeek (Beitrag 1345620)

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

Abgesehen vom Erstellen eines Repositorys (das mache ich lieber mit der Konsole) finde ich Git Cola sehr praktisch und übersichtlich.

[himitsu]

Ich nutzte Git zwar selber nicht, nur wenn ich mal was aus irgendeinem Git-Repo runterladen muß.
Hab mir dafür Tortoise Git installiert, damit es wenigstens zum Tortoise SVN passt und ich mir für Git keine selten benötigte Consolenparameter merken muß.

Wäre nur zu praktisch, wenn Tortoise bissl intelligenter wäre und aufräumt.
(z.B. wenn ich in 'nem SVN-Repo bin, dann brauch ich kein Git-Menü im Explorer, bzw. abgesehn vom Auscheckten/Exportieren können auch beide Menüs kombiniert/gleich aufgebaut sein)

[dGeek]

Was wäre eigentlich, wenn Githib mal gehackt wird? Dann hätte der Pirat doch quasi alle Source-Codes?

[Aviator]

Zitat:

Zitat von dGeek (Beitrag 1345620)

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

Atlassian bietet für solche Dinge kostenlos den SourceTree an. Man muss sich nur einmal registieren und kann den dann nutzen. Wird auch regelmäßig geupdatet. Der kann Git und Mercurial und ist eigentlich relativ einfach zu bedienen.

[vagtler]

Zitat:

Zitat von dGeek (Beitrag 1345627)

Was wäre eigentlich, wenn Githib mal gehackt wird? Dann hätte der Pirat doch quasi alle Source-Codes?

Git != GitHub

https://de.wikipedia.org/wiki/Git
https://de.wikipedia.org/wiki/GitHub

[dGeek]

Ja ist doch egal wie man es schreibt :P Ich meine die Website :P

[vagtler]

Zitat:

Zitat von dGeek (Beitrag 1345633)

Ja ist doch egal wie man es schreibt :P Ich meine die Website :P

Ja, ich auch. Verstehst Du, dass Git und GitHub zwei ganz unterschiedliche Dinge sind?

[jaenicke]

Zitat:

Zitat von dGeek (Beitrag 1345620)

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

Dazu habe ich hier ein Beispiel beschrieben (Tortoisegit):
http://www.entwickler-ecke.de/viewtopic.php?t=115462

[bra]

Zitat:

Zitat von dGeek (Beitrag 1345627)

Was wäre eigentlich, wenn Githib mal gehackt wird? Dann hätte der Pirat doch quasi alle Source-Codes?

Ja, hätte er. Aber da auf Github größtenteils OpenSource-Projekte liegen, dürfte der Nutzen ziemlich gering sein. Und Git bedeutet nicht, dass der Source auch zwingend auf Github liegt.

[Phoenix]

Zitat:

Zitat von dGeek (Beitrag 1345620)

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

SourceTree oder GitKraken.

[hoika]

Hallo,
nette Diskussion, geht also nicht nur mir so ;)

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.

Wie kann ich denn nur eine Teil einer Datei committen ???
Klar kann ich die anderen Änderungen vor dem Commit löschen (Sicherheitskopie !!!),
aber committed wird doch immer eine Datei?

[Der schöne Günther]

Ich habe leider kein Subversion mehr installiert und kann dir keine Bilder machen.

Hier die Anleitung
https://tortoisesvn.net/docs/nightly...commit-restore

Und hier ein Bild
https://writesoft.files.wordpress.co...ter_commit.png


Im Endeffekt war es ein Anhaken von "Stelle mir die Datei danach wieder her", dann Rückgängig-Machen deiner ungewollten Änderungen, dann committen, dann waren die restlichen Änderungen wieder da.
Hört sich kompliziert an, ich hatte es ständig gemacht. In Mercurial (git nutze ich fast nicht) schiebe ich das ungewollte immer auf den stash und danach wieder rein. Die Subversion-Variante hat mir sogar besser gefallen.

[Aviator]

Zitat:

Zitat von Phoenix (Beitrag 1345687)

Zitat:

Zitat von dGeek (Beitrag 1345620)

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

SourceTree oder GitKraken.

Siehe #17 :stupid:

[pertzschc]

Zitat:

Zitat von dGeek (Beitrag 1345620)

Gibt es auche ordentliche GUI für Git (lokal, nicht online), die auch funktioniert?

http://www.syntevo.com/smartgit/

Grüße, Christoph

[Bambini]

Kleine Frage am Rande: Nutzt jemand den Microsoft Team Foundation Server mit/für Delphi:
http://stackoverflow.com/questions/8...er-in-delphi-7