SVN richtig verwenden?

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

[Angel4585]

Oh man wenn man SVN jetz ne Weile benutzt und das Konzept dahinter halbwegs verstanden hat fängt man bei Mercurial irgendwie trotzdem wieder bei 0 an

Bei SVN mach ich vom Repository(gibt nur eins) ein Checkout und arbeite dann wie gewohnt an meinem Code.

Bei Mercurial gibts ja nicht nur ein Repository quasi auf dem Server sondern auf jedem Client nochmal eins.
Und wenn ich das recht verstehe arbeitet man immer direkt im Repository aufm Client, was bei svn ja nicht geht man man man
Und wenn man mit seinen Änderungen durch ist, committet man in die lokale Kopie und synchronisiert danach die Repositories.

Besonders schön find ich auf jedenfall die grafische Darstellung

Und bei Mercurial hat man immer die aktuellen Codedateien da was bei Subversion nicht der Fall ist da das rein auf ner Art Datenbank basiert, seh ich das richtig?
Wobei die Änderungen bei Mercurial denk ich auch in ner Datenbank gespeichert werden, alles andere macht eig kein Sinn.

Naja ich danke euch auf jedenfall für die Tipps und Links, werd mich da mal noch tiefer einarbeiten.

[Phoenix]

Im Prinzip ja. Bei SVN hast Du nur ein Repo, und auf ggf. mehreren Clients lokale Working-Copies, bei Mercurial kannst Du belibig viele Repositories klonen (und zwar immer mit kompletter historie).
Du trägst also immer eine Kopie des Repos (und ja, da liegt irgendeine DB hintendran) mit Dir rum und kannst sie beliebig oft mit den anderen Repos in beliebige Richtungen synchronisieren.

[Lemmy]

Noch was zu SVN vs. Mercurial:

Ich nutze SVN - insbesondere deshalb recht gerne weil ich hier den Vorteil habe, dass mein Repro auf einem Server liegt - d.h. mit der Versionsverwaltung habe ich gleichzeitig ein Backup meines Codes. Bei Mercurial wären, wenn ich die selbe Systematik möchte schon 2 Checkins (oder puts) notwendig: einen ins lokale Repro und einen ins zentrale.

Und auch noch das: Sollte ich mal wieder mit mehreren an einem Projekt arbeiten müssen würde ich Mercurial auf jeden Fall den Vorzug geben - denn SVN und Mergen ist eine Geschichte für sich...

Grüße

[Angel4585]

Wie macht man das eigentlich wenn man externe Bibliotheken hat? kommen die mit in die Versionsverwaltung oder wird das irgendwie ausserhalb davon verwaltet? Also seien es jetzt DLLs die mit ausgeliefert weden oder in Java jars die ins Projekt eingebunden werden?

[Phoenix]

Theoretisch wie man mag. Ich habe die normalerweise in einem anderen Repo liegen und ziehe die via SVN:externals aus diesem anderen Repository rein. Das hat den Vorteil, dass ich bei Updates nur die neue Version committen muss, und dann bei jedem abhängigen Projekt separat entscheiden kann, welche Revision aus dem anderen Repo reingezogen und damit verwendet wird. Aber da gibt es glaube ich zigtausend verschiedene Wege das anders zu lösen.