Subversion Struktur ändern

[zowo]

Hallo!

Ich habe folgendes Problem. Ich habe meine SVN-Repository schon vor längerer Zeit aufgesetzt und damals nicht darauf geachtet, die gewöhnliche Ordner-Struktur mit branches/trunk/tags herzustellen. Stattdessen hab ich nur einen Projekt-Ordner der alle Dateien enthält.

Wie gehe ich jz am besten vor? 3 zusätzlicher Ordner auf der selben Ebene erstellen und dann den Projekt-Ordner in den Trunk-Ordner verschieben? Klingt ja im Prinzip nicht schwer ... aber muss ich da noch irgendwas beachten?

• wie sieht es mit der Versionierung aus bzw. den Revisionen kommt da dann etwas durcheinander?
• kann es bei den Dateirechten auch zu Problemen kommen? ist ja bei Ubuntu bzw. Linux auch nicht so unüblich?
• muss auch in den Ordner branches bzw. tags etwas reinkopiert werden oder werden diese erst später befüllt wenn man z.B. einen Snapshot des aktuellen Entwicklungsstands macht?

Danke für die Hilfe!

[gfoidl]

Hallo,

zu beachten ist, dass mit SVN verschoben wird, damit die Versionierung erhalten bleibt. Bei Win geht das mit Verschieben durch die rechte Maustaste - bei Ubuntu steht das sicher in der Hilfe. Bei den Dateirechten für Ubuntu kann ich nichts sagen.
branches und tags werden dann befüllt, wenn du entweder einen Zweig erstellst od. den aktuellen Stand markierst.

mfG Gü

[zowo]

Ok danke hab TortoiseSVN verwendet und es hat problemlos funktioniert

hast du vielleicht ein paar Tipps wie man jz am besten vorgeht, wenn zusätzliche Entwickler am Projekt mitarbeiten? es soll dem Scrum-Prozess gefolgt werden, sodass jeder Entwickler seine eigene User-Story erhält ... soll dann jeder User-Story als Branch ausgelagert werden, der Entwickler entwickelt dann und mergt am Ende wenn alles funzt den Stand wieder in den trunk?

gibt es vielleicht irgendwo Tutorials für eine verteilte Entwicklung mit SVN oder so etwas wie best practice

danke

[Christian Marquardt]

Sicherlich nicht so. Jeder Entwickler entwickelt mit einem ausgecheckten trunk auf den lokalen Rechner. Fertige Ergebnisse werden in den trunk eingecheckt. Ein branch wird nur angelegt, wenn von dem jetzigen Zweig abgewichen werden soll -> bsp. Patch.

[gfoidl]

Hallo,

schau dir dazu auch A Visual Guide to Version Control und ALM Rangers Branching and Merging guide for Visual Studio 2012 is availabl an.

mfG Gü

[zowo]

Sicherlich nicht so. Jeder Entwickler entwickelt mit einem ausgecheckten trunk auf den lokalen Rechner. Fertige Ergebnisse werden in den trunk eingecheckt. Ein branch wird nur angelegt, wenn von dem jetzigen Zweig abgewichen werden soll -> bsp. Patch.

ok wie kann man dann gewährleisten, dass der trunk immer stabil bleibt? weil es schleichen sich immer irgendwo Fehler ein.

@gfoidl

danke für die Links!

[Christian Marquardt]

Wer einen fehlerhaften trunk verursacht, muss einen ausgeben.
Wenn der Entwickler lokal getestet hat, sollte der trunk sauber bleiben. Die Fehler die immer drin sind, wirst du nicht vermeiden koennenn.
Die werden wohl nur bei einem globalen Test gefunden. Wenn ueberhaupt.

[zowo]

Wer einen fehlerhaften trunk verursacht, muss einen ausgeben.

hehe guter Ansatz danke für die Tipps!

[zowo]

... nachdem ich nun die Struktur des Repo's geändert habe und für die Weiterentwicklung des Layouts einen neuen Branch erstellt habe, möchte ich nun die aktuellen Änderungen im Trunk auch in den Branch übernehmen. Leider funktioniert das nicht so richtig.

Erstellt habe ich den Branch mit folgenden Befehl

svn copy file:///var/local/subversion/myapp_svn/myapp_beta/trunk 
file:///var/local/subversion/myapp_svn/myapp_beta/branches/foundation-update 
-m "creating private branch for foundation update"

... das hat super geklappt der Branch kann lokal ganz normal ausgecheckt werden. Ich schaffe es aber leider nicht die Änderungen am Trunk mit dem Branch zu mergen. Wenn ich über die Kommandozeile z.B. mit

svn merge \
file:///var/local/subversion/myapp_svn/myapp_beta/branches/foundation-update \
file:///var/local/subversion/myapp_svn/myapp_beta/trunk

die Änderungen in den Branch mergen will, erhalte ich die Meldung das "file:///var/local/subversion/myapp_svn/myapp_beta/trunk" keine Working-Copy ist. Anscheinend muss beim "merge" die Pfadangabe anders erfolgen ... leider habe ich keine Idee wie ich diese angeben soll, da ich ja z.B. mit cd /var/local/subversion/myapp_svn/myapp_beta/trunk ... nicht mal in diese Verzeichnis wechseln kann.


Hat jemand eine Idee welche Möglichkeiten es in diesem Zusammenhang gibt?

[Falk Prüfer]

Hallo,

ich bin kein SVN-Profi, aber das Mergen des Trunk in einen Branch desselben ist mit Sicherheit kein gangbarer Weg. Umgekehrt wird ein Schuh draus. Du kannst die Änderungen am Branch wieder in den (mittlerweile auch weiterentwickelten) Trunk mergen.

Gruß Falk

[fanderlf]

Wir verwenden FeatureToggles. Heisst es gibt irgendwie eine konfigurierbare Stelle z.B. in einer .config Datei an der ich sage ob ein neu entwickeltes Feature aus oder an ist. Im SVN sowie dann auf allen Clients ist das Toggle erstmal aus. Lokal kann ich mir das Toggle einschalten oder auch jeder andere der es gerne sehen würde.
Wenn ich nun mit der Story fertig bin (im übrigen sollten in Scrum möglichst auch ALLE Entwickler an EINER Story arbeiten und nicht jeder an seiner eigenen - aber das nur am Rande), dann schaltet man das Toggle an und committed es ins SVN. Somit ist es für alle sichtbar und wäre auch im Live Code aktiv. Sobald der Code ausgerollt ist und man festgestellt hat dass keine Fehler auftreten kann das Toggle dann aus dem Code gelöscht werden.
Ich weiss nicht ob ihr ein Staging für die verschiedenen Entwicklungsstadien eueres Produkts habt. Wir haben z.B. 3 Umgebungen. CI ist die "Entwicklungsumgebung". In dieser Umgebung sind praktisch immer alle FeatureToggles an. Dann haben wir eine Stable, die nur 1-2 mal pro Tag betankt wird und den Live Zustand der FeatureToggles als Basis hat. Weiterhin haben wir noch Ref Umgebung die in der Live Umgebung steht und die dann betankt wird wenn alle Tests auf Stable erfolgreich waren.
Der Vorteil an FeatureToggles ist dass man hier nicht verschiedene Branches in SVN hat, denn für jeden Branch bräuchte ich ja zwangsläufig auch eigene Umgebungen im Staging. Ein weiterer Vorteil ist auch dass man die Toggles offline releasen kann und die auf Live trotzdem auch mal aktivieren um zu sehen ob der Code auf den Live Systemen auch funktioniert. Das hängt jetzt aber davon ab was ihr entwickelt (wir haben eine Webplattform).
Hier kannst Du etwas mehr dazu lesen: http://atombrenner.blogspot.de/2011/...les-links.html

Achja... im Code steht nicht mehr als:

[highlight=c#]
if(featureToggleIsEnabled)
{
//neuer Code hier
}
else
{
//alter Code hier
}
[/highlight]

Wenn man wirklich 100% sauber arbeitet kann man hier auch gleich noch das Open Closed Principle anwenden, sofern man einen DI zur Verfügung hat. Dazu kopierst Du die alte Implementierung Deiner Klasse und änderst das was Du ändern möchtest. Danach Togglest Du einfach die Registrierung im DI. Dann hast Du wenn Du das FeatureToggle ausschaltest zu 100% wieder den Zustand vor der Änderung.

[zowo]

Hallo,

ich bin kein SVN-Profi, aber das Mergen des Trunk in einen Branch desselben ist mit Sicherheit kein gangbarer Weg. Umgekehrt wird ein Schuh draus. Du kannst die Änderungen am Branch wieder in den (mittlerweile auch weiterentwickelten) Trunk mergen.

Gruß Falk

Hy, ja das man am Ende den Branch wieder in Trunk mergen kann das weiß ich wobei ich mir auch hier die Frage stelle, wie soll der Befehl aussehen ... weil ich nehme an, dass da wieder die Meldung kommen wird "no working copy"

bezüglich trunk in branch mergen ... das habe ich hier gefunden

http://web-rocker.de/2011/01/subvers...e-reintegrate/

[fanderlf]

Das geht definitiv wir haben das früher auch gemacht. Es ist ja eigentlich auch egal in welche Richtung du merged. Wenn Du allerdings einmal wieder in den Trunk gemerged hast musst Du den Branch wegwerfen (wenn Du wieder einen brauchst einen neuen ziehen). Die Commits vom Trunk in den Branch zu mergen ist eine gute Idee um merge konflikte möglichst früh zu lösen. Später kann das echt hässlich werden.