Moin Moin!
Hi,
vielleicht entdecke ich ja im Zuge dieser Diskussion endlich mal, was an so einer Versionsverwaltung so toll ist.
Undo.
kann ich jederzeit und ebensogut auch mit der Methode "Snapshot als Verzeichniskopie".
Klar, aber Rechtsklick -> Commit, Kommentar, Enter bzw. svn commit -m "Kommentar" macht weniger Arbeit als mir erstmal wieder einen neuen Snapshot-Namen auszudenken, das ganze Zeugs zu kopieren, und den Commit-Kommentar in irgendeine Datei einzupflegen.
Das "Wer" ergibt sich aus der Zuordnung der Projektbereiche zum jeweiligen Bearbeiter.
Nicht bei Krankheitsvertretungen etc. Nicht, wenn mehrere Leute an einem Stück SW arbeiten.
Was machst Du in Deinem Modell, wenn ein Kollege ausfällt? Warten, bis der Kollege wieder kommt?
Wenn es eine absehbar kurze Ausfallzeit ist (ein Tag, zwei Tage), dann ja. Sonst muss eben jemand anders einspringen und diesen Teil vorübergehend übernehmen. Das ist aber grundsätzlich problematisch, denn das Einarbeiten in fremde Software dauert auch unter günstigsten Umständen eine gewisse Zeit.
Richtig. Die kann, wenn man eng zusammenarbeitet, aber recht kurz sein. Und wenn Du die Arbeit eben nicht nach Source-Dateien aufteilst, sondern nach anfallenden Änderungen, dann faßt jeder irgendwann mal alle Dateien an.
Mit einer Versionsverwaltung kannst Du stumpf seinen letzten Stand forken und dort weiter entwickeln. Wenn der Kollege wieder auftaucht, kann er Deine Weiterentwicklung mergen und weiter arbeiten.
Also kein Unterschied zu "meiner" Methode".
Außer, dass Du viel mehr manuell erledigen mußt.
Der Normalfall dürfte doch sein, dass jeder Entwickler seinen abgegrenzten Teilbereich des Projekts mit klar definierten Schnittstellen bearbeitet, in den ihm kein anderer reinzupfuschen hat.
Das ist der akademische Traumfall. Die Realität sieht deutlich hässlicher aus. Du hast Tonnen von Legacy-Code, von denen niemand so recht weiß, was darin passiert, jeder hat mal drin herumgefummelt, und eigentlich hofft man immer, das einem das Zeug nicht um die Ohren fliegt.
Das ist wohl wahr, aber ein ganz anderes Problem, das mit dem Topic hier nichts zu tun hat.
Doch. Mit einer Versionsverwaltung kannst Du zum letzten bekannt guten Zustand zurück, OHNE dich durch Tonnen von verteilt herumliegenden Snapshots kämpfen zu müssen.
Längst nicht jeder, der an Software rumbastelt, ist dafür auch qualifiziert. Leider. Das führt zu sehr gruseligen Konstruktionen. Siehe oben.
Klar. Das passiert dann aber auch mit dem ausgefeiltesten Versionskontrollsystem.
Richtig. Aber da merken die fähigeren Kollegen, die sich gelegentlich die Commits und Diffs ansehen, dass jemand Schrott baut, und können gegensteuern.
Ganz ehrlich, ich habe den Sinn eines Versionskontrollsystems bisher noch nicht verstanden. Wenn ich eine Version als "Milestone" konservieren will, dann archiviere ich den aktuellen Zwischenstand, und fertig. Das ist eine simple Kopieraktion (meinetwegen zusätzlich eine Komprimierung).
Das ist tagging, und mit Deiner Methode eine sehr teure Operation.
Ich bitte dich - im Zeitalter von Giga- und Terabyte-Platten?
Mal sehen:
SVN-Verzeichnis auf dem $WORK-Server belegt rund 500 MByte, das dürfte angesichts der großen Menge von Altlasten auch so in etwa die Größe eines vollständigen Exports sein, auf dem Du Snapshots aufsetzen würdest. Die ursprüngliche Größe liegt einige KByte drunter, aber nicht sehr viel, weil der Code hauptsächlich umgebaut wird, aber selten größere Mengen neuen Codes dazu kommen.
Die aktuelle Revisionsnummer ist 1037.
Du hättest jetzt etwas über 1000 Snapshots à 500 MByte herumliegen und damit eine 500 GByte-Platte komplett gefüllt.
Die aktuelle Revisionsnummer von Python, als Beispiel für ein Projekt mit mehr Entwicklern und mehr Entwicklungszeit ist irgendwas knapp unter 90.000. SVN selbst liegt, dank der Integration in Apaches Repository, mittlerweile bei über 1.300.000.
Es hat aber vor allem den Vorteil, dass auch jemand ohne dieses Versionskontrolldingsbums mal eben den kompletten aktuellen Projektstand vom Server ziehen kann.
Nächtlicher automatischer Export.
Man macht sich eben nicht von *noch einem* Tool abhängig.
Echte Programmierer kommen ohne alle Tools aus.
SVN kommt (wie auch andere Systeme) mit guten Betriebssystemen gleich mit, für den Rest gibt's die Software-Verteil-Software, die jedem User, der in der Gruppe der Entwickler ist, die Software installiert. Und in kleinen Läden, die keine automatische Software-Verteilung haben, muß sich der Entwickler seine Kiste ohnehin meistens selbst installieren.
SVN-Clients sind auch in diverse IDEs integriert, allen voran Eclipse. Microsoft hat mit VSS ähnliches für Visual Studio gestrickt.
Das ist nämlich ein Punkt, der *mich* oft stört, wenn Repos irgendwelcher Software im Internet angeboten werden: Man sucht meistens vergeblich nach einem Komplett-Download, sondern muss sich die Dateien einzeln ziehen und dabei auf die Hierarchie achten. Bei einem kompletten Snapshot als zip- oder sonstiges Archiv ergibt sich das von allein.
Äh, wie?
svn checkout svn://svn.example.com/svn/foo/bar/trunk, wenn Du basteln willst, svn export svn://svn.example.com/svn/foo/bar/trunk, wenn nicht.
Viele Projekte erzeugen auch automatisch Archive vom trunk und vom HEAD.
Ich ziehe also das Fazit, dass so ein Versionskontrollsystem die Chance für viel Bürokratie eröffnet, von der ich noch nie den Eindruck hatte, dass ich sie bräuchte. Weder für mich, noch für ein Team mit bis zu fünf Leuten.
Die *CHANCE* für viel Bürokrate. Out of the Box sind VCS aber sehr unbürokratisch. Du kannst - wenigstens bei SVN - jede Menge Hooks installieren, die Dir jede Menge Bürokratie bringen, angefangen bei automatischen Tests auf korrekten Coding Style. So einen Quatsch machen aber nur Bürokraten, denen man erlaubt, den Entwicklern reinzupfuschen.
Die zusätzlichen Meta-Informationen, wie etwa den Grund für die neue Version und die Änderung in Stichworten, werden sowieso als Kommentar im Quelltext notiert - oder als zusätzliches Dokument.
*DAS* artet in Bürokratie aus. Ich bin hier ($WORK) wortwörtlich von Tonnen von Papier umgeben, auf dem Amateure ihre historischen Programmversionen und Änderungsdokumentationen ausgedruckt haben. Versionsverwaltung komplett auf Papier. Kein Witz. Und die Idee mit "Ich schreib Änderungen in Kommentare" treibt sich hier auch rum. Mit dem Ergebnis, das ungefähr die Hälfte der Änderungen versehentlich oder aus Faulheit eben NICHT als Änderungen mit einem Kommentar gekennzeichnet sind, und ebenso nur ungefähr die Hälfte der Änderungen tatsächlich dokumentiert sind. Die bürokratischen Richtlinien dafür (von denen es hier reichlich gibt), geben etwas anderes vor, aber Richtlinie und Realität haben eben oft nur sehr wenig gemeinsam.
Wie kommentierst Du übrigens gelöschte Zeilen? ;-)
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
Felix Riesterer
Der Martin
seth
