Subversion und VisualSVN für Ein-Mann-Entwicklung

[bra]

Ich kann auch jedem nur raten, ein VCS zu nutzen, selbst wenn man nur lokal allein an einem Projekt arbeitet. Und wenn ich solche Aussagen höre wie "wenn man selbst dran arbeitet, weiss man genau was man gemacht hat", kann ich nur den Kopf schütteln. Wenn ich in einem Projekt Änderungen an zig verschiedenen Stellen mache, weiss ich das hinterher nicht mehr im Detail, wo genau das war. Da ist ein VCS einfach Gold wert. Aber es gibt auch Leute, die schreiben Programme lieber in einem Konsoleneditor ohne Syntaxhighlighting und so weiter. Wer es braucht...

[jaenicke]

Zitat:

Zitat von einbeliebigername (Beitrag 1352822)

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.

Wie wäre es denn mit mehr Details was genau du daran als Nachteil empfindest?
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?
Dass das Mergen durch das reine Speichern von Changesets in der Regel unproblematischer verläuft?
Dass bei der Kommunikation mit dem Server alles komprimiert wird und das Ein- und Auschecken und insbesondere initiale Herunterladen eines Repositorys dadurch extrem schneller ist?

[einbeliebigername]

Hallo,

Zitat:

Zitat von mse1 (Beitrag 1352829)

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.

Zitat:

Zitat von mse1 (Beitrag 1352829)

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.

Zitat:

Zitat von Sherlock (Beitrag 1352832)

Branching mit SVN, ist der einhelligen Meinung aller Beteiligten nach suboptimal.

Kannst du das mal bitte erklären was, wo und wieso! Ich finde das Verzweigen im SVN als sehr optimal, flexible und vielseitig.

Zitat:

Zitat von Sherlock (Beitrag 1352832)

Nicht nur darum hat man andere Versionsverwaltungen erfunden (und nein, git oder hg sind nicht älter als SVN, eher umgekehrt).

Bloß weil Etwas neuer ist, heißt das noch nicht, dass es auch besser ist!

Zitat:

Zitat von Sherlock (Beitrag 1352832)

Branching ist mit den modernen Versionskontrollsystemen mit Null aufwand verbunden, da jeder Commit prinzipbedingt innerhalb eines Branches erfolgt.

Richtig, mit SVN hat man beim Branching null aufwand (Wenn es keine Abhängigkeiten zwischen Repositorys gibt).

Zitat:

Zitat von Sherlock (Beitrag 1352832)

Dies kann jetzt eben immer der selbe Branch sein, oder man führt einfach einen neuen ein, und schon hat man zwei bis n Branches mit denen man treiben kann, was man will.

Du beschreibst da auch SVN.

Zitat:

Zitat von Sherlock (Beitrag 1352832)

Hier etwas zum Thema Branching und damit auch Merging in SVN gegenüber den modernen Systemen wie hg oder git: http://softwareengineering.stackexch...out-svn-merges

War jetzt für mich nicht hilfreich deine Meine zu verstehen.

Zitat:

Zitat von jaenicke (Beitrag 1352845)

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.

Zitat:

Zitat von jaenicke (Beitrag 1352845)

Dass das Mergen durch das reine Speichern von Changesets in der Regel unproblematischer verläuft?

Ist bei SVN auch so.

Zitat:

Zitat von jaenicke (Beitrag 1352845)

Dass bei der Kommunikation mit dem Server alles komprimiert wird und das Ein- und Auschecken und insbesondere initiale Herunterladen eines Repositorys dadurch extrem schneller ist?

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

Zitat:

Zitat von jaenicke (Beitrag 1352845)

Wie wäre es denn mit mehr Details was genau du daran als Nachteil empfindest?

Einiges habe ich oben schon erwähnt.
Für Git gibt es keine gescheite API. Und nein, die Ausgabe eines Konsolenprogramms ist keine API. (K.-o.-Kr*ite*ri*um)
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)

[jaenicke]

Zitat:

Zitat von einbeliebigername (Beitrag 1352848)

Zitat:

Zitat von jaenicke (Beitrag 1352845)

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:

Zitat von einbeliebigername (Beitrag 1352848)

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:

Zitat von einbeliebigername (Beitrag 1352848)

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:

Zitat von einbeliebigername (Beitrag 1352848)

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:

Zitat von jaenicke (Beitrag 1352856)

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:

Zitat von bra (Beitrag 1352857)

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:

Zitat von jaenicke (Beitrag 1352858)

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

[Benedikt Magnus]

Zitat:

Zitat von bra (Beitrag 1352860)

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

[himitsu]

Was die Build-Nummer in der Versionsnummer ist, wird nicht genau definiert.
* es kann eine Hochzählende Nummer sein, bei jedem Build
* manchne setzen da das Build-/Compilerdatum ein (Tag im Jahr, MMDD oder YYMM, bzw. YYYYMMTT bei Versionsinfo mit LONGWORD)
* man kann da gern die Revisionsnummer (ala SVN) einsetzen
* andere eine Fortlaufende Nummer nach irgendwelchen anderen Mustern
* Viele nutzen die garnicht
* ...

Man kann die Verionsinfos auch nach zwei grundlegenden Mustern "zerlegen"
* Major.Minor.Release.Build (Word.Word.Word.Word)
* Major.Minor.Irgendwas (Word.Word.LongWord) , falls einem WORD (0-32767) nicht ausreicht (einige Programme, wie z.B. die Delphi-IDE können nur 0-MaxSmallInt :stupid:)

Zitat:

Zitat von Harry Stahl (Beitrag 1352740)

War zwar (als Bonner natürlich) da, aber da war mein Interesse an SVN-System noch nicht geweckt, daher leider verpasst...
Schade, dass es von den Delphi-Tagen keine Videoaufzeichnungen gibt...

Es muß sich nur wer finden, der das aufnimmt.
Ich hatte Daniel mal auf den DT gefragt und er meinte damals, dass es nur wer machen müsste.

Eventuell könnte man das auch zusätzlich als LiveStream rausschicken, für Alle, die nicht direkt kommen können. :angle:
(womöglich gegen ein kleines Endgeld/Aufwandsenschädigung, entsprechend dem normalen Eintrittsgeld)

[einbeliebigername]

Hallo,

Zitat:

Zitat von jaenicke (Beitrag 1352856)

Zitat:

Zitat von einbeliebigername (Beitrag 1352848)

Zitat:

Zitat von jaenicke (Beitrag 1352845)

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:

Zitat von jaenicke (Beitrag 1352856)

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:

Zitat von jaenicke (Beitrag 1352856)

Zitat:

Zitat von einbeliebigername (Beitrag 1352848)

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:

Zitat von jaenicke (Beitrag 1352856)

Zitat:

Zitat von einbeliebigername (Beitrag 1352848)

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.