Subversion und VisualSVN für Ein-Mann-Entwicklung

[jaenicke]

Zitat von einbeliebigername:

Und wie finde ich zu einer Buildnummer den passenden Sourcecode.

In der Liste der Änderungen pro Build in der Buildmaschine. Inklusive Links zu den entsprechenden Tickets, Entwicklungsvorgängen usw., die automatisch als solche erkannt werden, wenn man die in den Commit schreibt.
In den JIRA-Vorgängen wiederum kommentiert die Buildmaschine, dass ein Fix in Build XY enthalten ist. So hat man überall immer Links zwischen den einzelnen Informationen.

[himitsu]

Wir lassen unser Programm von FinalBuilder generieren ... da schreibe ich auch vom SVN die Revision und den Branch in eine INC, was man dann im Info-Fenster des Programms lesen kann.
Die Versionsnummer kommt aus einer INI (wird eingestellt über einen Dialog im FB und das wird dann als Versionsinfo in einer *.RC / *.RES abgelegt und in jede EXE/DLL/BPL eingebunden.


SVN erstellt die genannten LazyCopies, bei Branch/Tag, also erstmal nur 'nen Link auf das Verzeichnis/Datei+Revision,
und bei Änderungen am verlinkten Objekt, dessen Properties oder einem untergeordneten Objekt wird dann eine Kopie der geänderten Objekts (Datei/Verzeichnis) erstellt ... CopyOnWrite.

Reine Verlinkungen werden über die Properties erledigt, genauer über das Property svn:externals (kann auf eine externe oder interne Datei/Verzeichnis zeigen)

[einbeliebigername]

Hallo,

ich glaube das ist jetzt immer mehr OT.

Zitat von jaenicke:

In der Liste der Änderungen pro Build in der Buildmaschine.

Ich habe keine Buildmaschine, da bei mir Builds nicht aus Spaß gemacht werden. Ich mache zu 95% ein Release-Build wenn ich mit einer Aufgabe/Fehlerbeseitigung fertig bin und dann aber sofort (aus der Entwicklungsumgebung heraus, weil die sowieso gerade dann offen ist). Dann wird das was hinten rauskommt manuell getestet (Abschlusstest) und anschließen deployed. Bei einem Projekt gibt es noch nicht mal ein Deployment (weil es einfach keiner bezahlt). Dort wird nach dem Release-Build das teilweise manuell beim Kunden installiert und beim Kunden der Abschlusstest gemacht.
Also Anlaufstelle bleibt das Repository. Dort muss immer anhand der Versionsnummer der Sourcecode gefunden werden können. Bei SVN kein Problem, dort hat man quasi aus der Versionsnummer heraus einen direkten Link auf den Sourcecode.

Zitat von jaenicke:

In den JIRA-Vorgängen wiederum kommentiert die Buildmaschine, dass ein Fix in Build XY enthalten ist.

Auch Ticketsysteme hat nicht jeder im Einsatz, bzw. will nicht jeder Kunde benutzen.

[mse1]

Zitat von einbeliebigername:

Zitat von mse1:

Beim "veralteten Linux Konzept" Git geschieht das Umschalten zwischen Branches durch "git checkout <BRANCHNAME>", nix da mit Unterverzeichnissen anlegen und so.

Und schon wieder ein Nachteil. Wenn man kein Verzeichnis anlegen muss (vermutlich kann man das auch nicht in Git), wird man auch nicht gezwungen seine Tads/Branches zu strukturieren.

Richtig. Das Konzept der den Schnapschuss-Ketten mit Namen ist so flexibel, dass man die "Struktur" solange verändern kann, bis sie für die eigene Arbeitsweise optimal ist.

Zitat:

Zitat von mse1:

In MSEgit reicht ein Klick in die 'C'-Spalte der entsprechenden Zeile der Branches-Liste. Dazu ist keine Serververbindung notwendig, da im ".git" Archiv im Arbeitsverzeichnis die gesamte Historie enthalten ist. Verblüffenderweise sind Git-Clones trotzdem meistens kleiner als entsprechende SVN-Checkouts.

Und das ist auch so ein Nachteil von Git. Ich habe auf meinen SSD's nicht genug Platz um das gesamte Internet mit seiner Historie speichern zu können. Mir reich das was ich gerade verwende. Da brauche ich nicht den veralteten Mist, der sich in der installierten Delphi-Version sowieso nicht verwenden lässt, auf der Platte.

Das riecht jetzt stark nach Troll.
Selbstverständlich lässt sich auch nur ein Teil der Schnappschüsse "clone"en. Komfortables Zusammenarbeiten von verschiedene Branches ist dann natürlich nicht mehr möglich, wenn der gemeinsame Vorgänger fehlt. Fehlende Zustände lassen sich falls notwendig nachträglich aus einem anderen Repository nachladen.

[mse1]

Zitat von einbeliebigername:

Also Anlaufstelle bleibt das Repository. Dort muss immer anhand der Versionsnummer der Sourcecode gefunden werden können. Bei SVN kein Problem, dort hat man quasi aus der Versionsnummer heraus einen direkten Link auf den Sourcecode.

Das ist bei Git nicht anders. Die Versionsnummern sind einfach etwas länger.
Das Kommando wäre "git checkout <VERSIONSNUMMER>". Man muss von der Versionsnummer lediglich soviel Zeichen angeben, bis sie im Repository eindeutig ist.

[Namenloser]

Zitat von einbeliebigername:

Nein nehmen auf gar keinen Fall Git. Es gibt zwar viele Leute die diese veralteten Konzepte aus der Linuxwelt toll finden, sie sind es aber nicht. Sie sind schrecklich. Git hat nur einen Vorteil, dass es ein verteiltes System ist. Aber bei genauer Betrachtung ist das dann auch wieder ein Nachteil, wie alles andere bei Git. Deshalb igittigitt.

Autsch. Das "veraltete" Git ist neuer als Subversion. Und es wurde gerade entwickelt, um die Mängel älterer Versionierungssysteme wie Subversion zu überwinden.

Zitat von einbeliebigername:

Zitat von mse1:

In MSEgit reicht ein Klick in die 'C'-Spalte der entsprechenden Zeile der Branches-Liste. Dazu ist keine Serververbindung notwendig, da im ".git" Archiv im Arbeitsverzeichnis die gesamte Historie enthalten ist. Verblüffenderweise sind Git-Clones trotzdem meistens kleiner als entsprechende SVN-Checkouts.

Und das ist auch so ein Nachteil von Git. Ich habe auf meinen SSD's nicht genug Platz um das gesamte Internet mit seiner Historie speichern zu können. Mir reich das was ich gerade verwende. Da brauche ich nicht den veralteten Mist, der sich in der installierten Delphi-Version sowieso nicht verwenden lässt, auf der Platte. Und ob die Git-Clones auf Dauer kleiner sind bezweifle ich. Bei Sourcecode mag das vieleicht etwas dauern. Aber wenn man auch Binärdateien, welche sich regelmäßig ändern, in der Versionsverwaltung hat, geht das bestimmt sehr schnell.

Das ist das einzige Argument, das ich gelten lassen kann. Allerdings glaube ich du überschätzt die Größe von Git-Repositories. Selbst das gesamte Repository des Linux-Kernels mit allen seinen Änderungen seit 2005 (!) ist gerade mal 1.5 GB groß. Wenn deine SSD so klein ist, dann hast du mein Mitleid. Nervig ist es höchstens, wenn man sehr langsames Internet oder eine Volumenbeschränkung hat. Allerdings gibt es zur Not auch Shallow Clones, mit denen man nicht die gesamte Historie laden muss. Somit gilt das Argument eigentlich also doch nicht.

Ich finde außerdem, der Vorteil, auf die komplette Historie Zugriff zu haben und jederzeit committen zu können, auch wenn den Server down ist oder man keine Internetverbindung hat, überwiegt diesen kleinen Nachteil, selbst wenn es denn einer wäre, bei weitem.

[Uwe Raabe]

Zitat von Namenloser:

Das ist das einzige Argument, das ich gelten lassen kann.

Das ist eher ein Argument für Git/Mercurial, weil es nämlich gerade nicht stimmt! Ich habe mal gerade ein SVN-Repo ausgecheckt (SVN 1.8). Der .SVN Folder hat eine Größe von 23 MB und enthält im Wesenltichen die Originale der gerade ausgecheckten Revision (eben eben nur der). Dasselbe SVN-Repo mit kompletter Historie aller Branches in Mercurial konvertiert belegt gerade mal 9 MB im .HG Folder, enthält aber eben die komplette Historie.

In der Regel sind die lokalen Repos eines DVCS deutlich kleiner als die von SVN vorgehaltenen lokalen Daten.

[Daniel]

Am Rande eingeworfen - und das gilt gewiss auch nicht für alle - aber ich erwarte schon eine konstruktive Auseinandersetzung mit dem Thema. Unabhängig davon, ob man nun SVN, Git, Mercurial oder den Ausdruck auf Endlospapier bevorzugt, sollte eine sachliche Diskussion in aller Interesse sein.

[Sherlock]

Ich denke, wir müssen niemanden bekehren. Wer mit seiner gegenwärtigen Arbeitsweise glücklich ist, dem sei es gegönnt. Schließlich kann das nicht jeder von sich behaupten.

Ich würde Neueinsteigern, wie dem TE, halt empfehlen gleich bei State-of-the-Art anzufangen, statt zunächst die Erfindungen des Rades nachzustellen....

Sherlock

[himitsu]

Bei SVN liegt es aber auch nur daran, dass SVN jede Datei einzeln und unkomprimiert im .SVN-Verzeichnis ablegt.
Komprimiert und in einer Archivdatei, da wäre "theoretisch" der Checkout nur einer Revision immer kleiner, als der aller/mehrerer Revisionen. (gleiche Komprimierungsmethode vorausgesetzt)
Allerdings ist im .svn auch nicht von jeder Datei eine Kopie drin. (eventuell gibt es keine Kopie von Dateien, wo man eh keinen Diff anzeigen kann, oder so? )

Man kann dann zwar "theoretisch" schneller auf die Daten der einzelnen Datei zugreifen, aber ingesamt ist das einfach nur 'ne blöde Idee gewesen. (aber schon besser, als das von früher, wo in jedem einzelnen Unterverzeichnis ein keines .svn rumgammelte)