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.