Subversion und VisualSVN für Ein-Mann-Entwicklung

[jaenicke]

Zitat von einbeliebigername:

Zitat von jaenicke:

Dass bei Git die Dateien eines Branches beim Anlegen eines neuen Branches nicht komplett kopiert werden? So dass du da viel schneller und einfacher mit mehreren Branches arbeiten kannst?

Ist bei SVN auch so.

Das stimmt nicht. SVN erstellt "lazy copies", d.h. die Dateien werden komplett kopiert sobald eine Änderung darin passiert. Das kannst du leicht testen. Nimm einfach ein neues Repository, checke eine große Datei ein, erstelle einen Branch und ändere diese dort und du wirst sehen, dass das Repository entsprechend größer ist.

Zitat von einbeliebigername:

Das war mir neu. Aber bei Repositorys, wo es sehr viele Versionen gibt, dauert es dann doch länger (Ich meine das bei JCL und JVCL beobachtet zu haben. Kann aber auch an falscher Wahrnehmung oder anderen Umständen gelegen haben).

Das ist theoretisch richtig, dass du ggf. mehrere Branches holst, aber das einzelne Anfordern und Kopieren von z.B. 20000 Dateien dauert trotzdem bei Weitem länger als das Kopieren von z.B. 50000 komprimierten. Zudem werden die Dateien ja bei mehreren Branches nicht mehrfach komplett in dem Archiv eingepackt.

JCL und JVCL sind da übrigens ein gutes Beispiel. Nach der Umstellung von SVN auf Git lief das Auschecken/Klonen extrem schneller. Eben weil es so viele kleine Dateien sind.

Zitat von einbeliebigername:

Für Git gibt es keine gescheite API. Und nein, die Ausgabe eines Konsolenprogramms ist keine API. (K.-o.-Kr*ite*ri*um)

Nie wirklich gebraucht außer für Buildskripte und die laufen ohnehin auf Kommandozeile.

Zitat von einbeliebigername:

In Git sind die Revisionen nicht aufsteigend durchnummeriert. Somit kann man nicht ein Verweis auf die Revision benutzerfreundlich mit in der Version der Exe aufnehmen. (K.-o.-Kr*ite*ri*um)

Dafür gibt es ja eine Buildnummer aus der Buildmaschine. Hast du in irgendeinem größeren öffentlichen Projekt schon einmal die Quelltextrevision gesehen? Nein, da steht in der Regel die Buildnummer dran.

[bra]

Zitat von jaenicke:

Dafür gibt es ja eine Buildnummer aus der Buildmaschine. Hast du in irgendeinem größeren öffentlichen Projekt schon einmal die Quelltextrevision gesehen? Nein, da steht in der Regel die Buildnummer dran.

Bei uns ist die Buildnummer die Revisionsnummer aus dem SVN.

[jaenicke]

Zitat von bra:

Bei uns ist die Buildnummer die Revisionsnummer aus dem SVN.

Um mal Haare zu Spalten:
Dann ist es auch keine echte Buildnummer.
Aber bei kleineren Projekten habe ich das auch schon gesehen, bei unseren alten Projekten war das teilweise auch so, allerdings hieß es bei uns auch Revision, nicht Buildnummer. Aber egal ob bei Microsoft, Adobe oder wo auch immer, da wirst du so etwas kaum finden. Habe ich jedenfalls noch nicht gesehen.

[bra]

Zitat von jaenicke:

Aber bei kleineren Projekten habe ich das auch schon gesehen, bei unseren alten Projekten war das teilweise auch so, allerdings hieß es bei uns auch Revision, nicht Buildnummer. Aber egal ob bei Microsoft, Adobe oder wo auch immer, da wirst du so etwas kaum finden. Habe ich jedenfalls noch nicht gesehen.

Ich bezweifle aber auch, dass die Nummer bei MS die tatsächliche Buildnummer ist, weil die praktischerweise meist genau auf gerade Zahlen kommen (Win 7: 7600, Win8: 9600...). Insofern ist der Begriff Build eh Käse
Außerdem verwendet MS doch sicher noch sein tolles Visual Sourcesafe, da gibt es sowas doch gar nicht

[Benedikt Magnus]

Zitat von bra:

Ich bezweifle aber auch, dass die Nummer bei MS die tatsächliche Buildnummer ist, weil die praktischerweise meist genau auf gerade Zahlen kommen (Win 7: 7600, Win8: 9600...). Insofern ist der Begriff Build eh Käse

Wer weiß? Vielleicht sitzt da ja ein Mitarbeiter und drückt noch ein paar Mal auf Erstellen, bevor sie es veröffentlichen...

[einbeliebigername]

Hallo,

Zitat von jaenicke:

Zitat von einbeliebigername:

Zitat von jaenicke:

Dass bei Git die Dateien eines Branches beim Anlegen eines neuen Branches nicht komplett kopiert werden? So dass du da viel schneller und einfacher mit mehreren Branches arbeiten kannst?

Ist bei SVN auch so.

Das stimmt nicht. SVN erstellt "lazy copies", d.h. die Dateien werden komplett kopiert sobald eine Änderung darin passiert. Das kannst du leicht testen. Nimm einfach ein neues Repository, checke eine große Datei ein, erstelle einen Branch und ändere diese dort und du wirst sehen, dass das Repository entsprechend größer ist.

Trotzdem wird beim Verzweigen nicht jede Datei kopiert. Eine Verzweigung ist nur ein Eintrag mit Verweis auf die Revision. Und ob bei Veränderung einer Datei dann eine Kopie erstellt wird, kann ich jetzt aus Zeitmangel nicht testen. Bemerkt habe ich davon jedenfalls noch nichts.

Zitat von jaenicke:

JCL und JVCL sind da übrigens ein gutes Beispiel. Nach der Umstellung von SVN auf Git lief das Auschecken/Klonen extrem schneller. Eben weil es so viele kleine Dateien sind.

Ich hatte ein anderes Gefühl. Und die Kompression der Kommunikation könnte man auch bei SVN umsetzen. Es müsste sich nur mal jemand hinsetzten und ein neues schnelleres Kommunikationsprotokoll basteln.

Zitat von jaenicke:

Zitat von einbeliebigername:

Für Git gibt es keine gescheite API. Und nein, die Ausgabe eines Konsolenprogramms ist keine API. (K.-o.-Kr*ite*ri*um)

Nie wirklich gebraucht außer für Buildskripte und die laufen ohnehin auf Kommandozeile.

Genau dafür und für die kleinen Helferskripte. Und die kleinen Helferskripte sind bei ca. 160 Repositorys sehr hilfreich.

Zitat von jaenicke:

Zitat von einbeliebigername:

In Git sind die Revisionen nicht aufsteigend durchnummeriert. Somit kann man nicht ein Verweis auf die Revision benutzerfreundlich mit in der Version der Exe aufnehmen. (K.-o.-Kr*ite*ri*um)

Dafür gibt es ja eine Buildnummer aus der Buildmaschine. Hast du in irgendeinem größeren öffentlichen Projekt schon einmal die Quelltextrevision gesehen? Nein, da steht in der Regel die Buildnummer dran.

Und wie finde ich zu einer Buildnummer den passenden Sourcecode. Ich habe den Sinn die Builds zuzählen noch nie verstanden. Bei mir gibt es in keinem Projekt eine Buildnummer. Die Kunden brauchen eine Versionsnummer um die verschiedenen Versionen auseinander zu halten. Diese nennen sie einem wenn sie Probleme haben. Und damit muss man den Sourcecode finden können. Bei SVN baut man cleverer weise die Revisionsnummer als Bestandteil der Versionsnummer ein. Dann kann man erst einchecken und dann das Build machen. Andersrum wäre mir das zu fehleranfällig.

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

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

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.

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