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