SVN richtig verwenden?

[Angel4585]

Guten Tag!

Ich habe bisher eher wenig Wert auf Versionsverwaltung gelegt, da in Schule sowie in Firma nix damit gemacht wurde (schon bissl erbärmlich für ne Firma).
Nunja ich schaue mir jetzt SVN für private Projekte genauer an und hab mir VisualSVN auf meinem Homeserver installiert.

Wie gehe ich jetzt richtig damit um?
Sachen über Versionsverwaltungen die ich gehört hab sind:
- Im trunk-Ordner liegen die aktuellen Entwicklungen
- Niemals nur im trunk arbeiten
- Im branch-Ordner liegen Ausgliederungen, wenn man zB ne andere Vorgehensweise testen will
- Nie unausführbaren Code commiten
- Es gibt mindestens zwei Arten sein Repository zu strukturieren

Code:

  A: 
    svn/project1/trunk 
    svn/project2/trunk
  B:
    svn/trunk/project1
    svn/trunk/project2

Alles was ich bisher über Versionsverwaltungen gelernt hab basiert auf der Idee, dass verschiedene Entwickler an einem Projekt arbeiten und jeder Entwickler hat einen konstanten Rechner.
Ich arbeite allerdings momentan allein an meinem Projekt und hab mehrere Rechner. Einmal mein Notebook unterwegs und einmal mein Rechner zuhause.
Beim Notebook kann ich nie garantieren wie weit ich mit coden komm weshalb da schonmal unfertiger Code rumliegt(hängt vom ÖPNV ab).
Wenn ich heimkomm möcht ich dann aber an meinem Rechner weitercoden, muss also unfertigen Code commiten was man aber ja nicht soll.

Meine Idee wär jetzt, ich leg einen working Ordner im Repo an in dem ständig der aktuelle Code kommt. Wenn ich ne fertige Verison hab kommt die in den trunk Ordner.

Oder was meint ihr? Wie macht ihr das so?
Habt ihr sonst noch Tipps zu Versionsverwaltung/SVN?

[Phoenix]

Vielleicht ist ja Subversion gar nichts für Dich sondern eher Git oder Mercurial.

Das sind verteilte Versionierungssysteme. Hier committest Du sehr häufig (auch nicht kopilierbares Zeug) in lokale Branches. Sobald der Branch (oder ein Teil davon) fertig ist, pushst Du ihn in das Repo auf Deinem Rechner daheim (oder pullst von da aus vom Notebook).
Bis dahin bleibt der aber lokal, 'verschmutzt' so nicht Dein Master-Repo und Du hast hinterher vor allem sogar die einzelnen Entwicklunsschritte in der Versionierung, die Dir bei SVN sonst fehlen würden.

Ansonsten: Ja nach Organisation - insbesondere wenn Du alleine bist - kannst Du schon auf dem Trunk arbeiten wenn Du parallel dazu einen früheren Branch als 'Release' vorhanden hast der in sich feature-Complete ist. Das stört nicht wirklich. Bei SVN ist das branchen und mergen nicht ganz so angenehm wie bei distributed Systemen wie Git oder Mercurial (HG).

[Angel4585]

Also würdest du empfehlen bei für jedes Release ein Branch zu erzeugen und sonst immer im Trunk zu arbeiten?
Was wenn irgendwann ein zweiter oder dritter Entwickler dazukommt?
Werden Branches überhaupt getrennt vom Rest behandelt? Also haben die wieder eigene Revision Nummern?
Dann könnte ich nämlich ein eigenen Branch anlegen und immer in den committen und erst wenn meine Version nichtmehr schmutzig ist in den Trunk damit.

SVN gefällt mir eigentlich schon soweit aber ich kann mir die andern auch mal anschauen.
Da ich momentan hauptsächlich mit Java/NetBeans arbeite bietet sich Mercurial evtl auch an, das ist genauso wie SVN direkt dort mit drin.

[Phoenix]

Zitat von Angel4585:

Also würdest du empfehlen bei für jedes Release ein Branch zu erzeugen und sonst immer im Trunk zu arbeiten?
Was wenn irgendwann ein zweiter oder dritter Entwickler dazukommt.

Jain. Nicht unbedingt. Du kannst natürlich auch für jedes neue Feature einen eigenen Branch anlegen und den dann wenn er abgeschlossen wieder zurück mergen. Das sollte man auch mit mehreren Entwicklern machen (wobei wir hier auch schon zu fünft auf dem Trunk gearbeitet haben, das geht ohne Probleme). Das Branchen und Mergen ist wie gesagt mit SVN nicht ganz so angenehm wie mit Git.

Zitat von Angel4585:

Werden Branches überhaupt getrennt vom Rest behandelt? Also haben die wieder eigene Revision Nummern?
Dann könnte ich nämlich ein eigenen Branch anlegen und immer in den committen und erst wenn meine Version nichtmehr schmutzig ist in den Trunk damit.

Nein. Ein Repository in SVN hat immer eine eineindeutige Revisionsnummer. Und die wird immer erhöht, egal in welchen Pfad commited wird. Trunk, branches und tags sind kein SVN-Feature, sondern lediglich eine Ordnerstruktur innerhalb der Versionierung, die sich mal irgendjemand ausgedacht hat und die deshalb ungeuer viele (aber nicht alle) Leute auch so nachbilden.

Zitat von Angel4585:

SVN gefällt mir eigentlich schon soweit aber ich kann mir die andern auch mal anschauen.
Da ich momentan hauptsächlich mit Java/NetBeans arbeite bietet sich Mercurial evtl auch an, das ist genauso wie SVN direkt dort mit drin.

Wie gesagt: War nur ne Idee bzw. ein Alternativvorschlag. Mir selber erschien das am Anfang ungeheuer komplex, aber letzlich habe ich alle meine privaten Projekte umgezogen. Ein riesen Vorteil ist halt, dass man lokal immer das komplette Repo inkl. aller Versionen hat. Das braucht freilich mehr platz, aber ich bin nicht auf eine Internetverbindung angewiesen wenn ich mal die Historie eines bestimmten Files angucken will etc. Und meine lokalen Commits inkl. Historie werden auch immer mit auf den Server (bzw. das, was ich als mein Master-Repo pflege) gesynced. So ganz uncool ist das nicht

[r2c2]

Der "traditionelle" Ansatz sind die hier schon erwähnten Feature Branches. Aber das hat seine Nachteile. Insbesondere das Mergen kann sehr unangenehm werden. Mit Git/mercurial/etc. wird das auch nur ein bisschen besser. Substantiell ändert sich an der Problematik dadurch nichts.

Wenn man alleine arbeitet, ist das alles nicht so tragisch, aber schon mit zwei Entwicklern wirds irgendwann unlustig. Deshalb vertreten manche (insbesondere Leute aus der "agilen" Ecke) eine andere Auffassung: Contiuous Integration. Dabei committed jeder auf den master/trunk/whatever und zwar häufig (mindestens einmal am Tag, eher häufiger).

Damit der Code funktionstüchtig bleibt, obwohl man nicht fertig mit der Implementierung ist, benutzt man Feature Toggles. Also Schalter, die neues Features an- und ausschalten.

Ich hab den Ansatz bisher noch nicht ausprobiert, aber er klingt vernünftig. Dass das Mergen fehleranfällig ist und nicht gerade Spaß macht, hab ich nämlich schon erfahren. Bei Gelegenheit will ich das also mal versuchen.

Informationen darüber:
http://www.thoughtworks.com/perspect...nuous-delivery (interessantes Video)
http://martinfowler.com/articles/con...tegration.html (unfangreicher Atikel)

mfg

Christian

[s.h.a.r.k]

Hier gibts auch noch einen interessanten Artikel, der zwar auf Mercurial genauer eingeht -- Git und Mercurial liegen, wie im Artikel angemerkt, aber scheinbar sehr nah beieinander.