Wie soll ich in Subversion eine neue Hauptversion meiner Anwendung einrichten?

10

Ich bin dabei, an einer neuen Version (Version 4) meiner kommerziellen Anwendung zu arbeiten. Ich benutze Subversion.

Wie würden Sie mir aufgrund Ihrer Erfahrungen, Fehler und Erfolge empfehlen, die neue Version in Subversion einzurichten?

Hier einige Informationen: Ich beabsichtige, wichtige Updates in Version 3 noch einige Zeit nach der Veröffentlichung von Version 4 zu veröffentlichen. Die gesamte Entwicklung neuer Funktionen erfolgt jedoch ausschließlich in Version 4.

Falls es relevant ist: Ich bin ein Solo-Entwickler für dieses Produkt, und das wird wahrscheinlich auch so bleiben.

EDIT: Mir sind die Tags und Zweige von SVN bekannt. Ich denke, was ich brauche, ist eine optimale Strategie für die Verwendung von Tags und Zweigen in meiner Situation.

version-control svn

— Steve McLeod
quelle

8

Sie möchten Zweige erstellen . Es klingt wie ein Zweig in Ihrem Quellbaum, normalerweise eine Kopie Ihrer Quelle, wenn Sie ihn freigeben. Sie würden sich für die kritischen Updates in diesen Zweig verpflichten und das Update aus diesem Zweig erstellen.

Was Sie gerade tun, wäre das trunkund Sie würden dort Version 4 codieren. Wenn größere Änderungen an Version 3 festgeschrieben werden und Sie diese in Version 4 haben möchten, führen Sie eine Zusammenführung vom Zweig (v3) zum Trunk (v4) durch, um die Änderungen auf den Trunk zu übertragen.

Sie können sich auch Tags ansehen , die wie Zweige aussehen , aber mit einer einzelnen Version verknüpft sind, normalerweise der letzten Version einer Version (oder der ersten).

— Karthik T.
quelle

Während Sie einen Zweig der vorherigen Version erstellen, können Sie auch für jedes von Ihnen erstellte Update / Release ein Tag erstellen. Auf diese Weise müssen Sie einen Zweig festlegen, und Sie können die Tags verwenden, um eine frühere Version zu erstellen, die Sie erstellt haben.

— Geerten

IIRC-Tags in svn sind nicht unbedingt mit einzelnen Versionen verknüpft, sie sind in der Tat identisch mit Zweigen in allen außer intension

— jk.

Tatsächlich sind Zweige und Tags in der Implementierung identisch, sie sind im Wesentlichen Kopien des Codes. Sie unterscheiden sich nur in der Konvention. Tags sollen auf eine bestimmte Revision verweisen, während Branch ein alternativer Entwicklungspfad sein soll.

— Karthik T

3

Es hängt davon ab, ob.

Sie können Version 4 im Trunk behalten und auf V4 weiterentwickeln. Version 3 wäre ein Zweig, den Sie nach Bedarf aktualisieren würden. Der Vorteil dieses Ansatzes besteht darin, dass Sie, wenn in V3 ein kritisches Problem entdeckt wurde, das auch in V4 vorhanden ist, die Datei (en) über die Zweige hinweg einfach zusammenführen können.

Die andere Möglichkeit besteht darin, ein völlig neues Repository für V4 zu erstellen. Dies gibt Ihnen einen Neuanfang. Der Nachteil ist, dass der Änderungsverlauf zurückgesetzt wird und Sie keine Dateien über Subversion zusammenführen können. Sie müssen ein Programm wie Beyond Compare verwenden, um Änderungen zusammenzuführen.

Persönlich würde ich beim ersten Ansatz bleiben. Erstellen Sie einen V3-Zweig und pflegen Sie den Code und die Aktualisierungen in diesem Zweig. Der neue V4-Code kann im Kofferraum entwickelt werden.

— Chuck Conway
quelle

2

Ich habe einen ausgezeichneten Leitfaden für diese Situation gefunden :

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too.

— Steve McLeod
quelle

0

Was Sie fragen, ist die zu verwendende Verzweigungs- (und Zusammenführungs-) Strategie. Also nimm den Posten von karthik t und nimm das als Rezept.

Lesen Sie für einige Hintergrundinformationen die folgenden Ressourcen:

SVN Red Book für das Repository-Layout (Einzel- oder Mehrprojekt-Repositorys)
Verzweigungsmuster In Ihrem Kontext verwenden Sie einen Release-Zweig pro Hauptversion
Software Configuration Management Patterns die Basistheorie, die in Subversion (und allen anderen CM-Systemen) verwendet wird. Sehen Sie dort die Muster , insbesondere die Release-Linie dort.

— mliebelt
quelle