Einzelnen Beitrag anzeigen

einbeliebigername

Registriert seit: 24. Aug 2004
140 Beiträge
 
Delphi XE8 Professional
 
#85

AW: Subversion und VisualSVN für Ein-Mann-Entwicklung

  Alt 7. Nov 2016, 22:50
Hallo,

Das "veraltete" Git ist neuer als Subversion.
Ich habe niemals behauptet das Git veraltet oder älter ist als SVN ist! Ich habe lediglich gesagt das einige Konzepte hinter Linux und dort kommt laut meinem Kenntnisstand Git her und man erkennt das deutlich, aus meiner Sicht veraltet sind. Und da meine ich im Falle Git dieses alles ist eine Datei-Konzept (müsste heut alles ist ein Objekt sein) und dieses Konsolenlastige. Ich habe doch keinen Monitor mit Millionen von Pixeln, welche bald Milliarden verschiedener Farben anzeigen können, um mich dann wieder mit Textoutput rumschlagen zu müssen.

Selbst das gesamte Repository des Linux-Kernels mit allen seinen Änderungen seit 2005 (!) ist gerade mal 1.5 GB groß.
Das ist ja mal eine Info. Ohne zu wissen hätte ich gedacht die haben mehr. Ist da alles vom ersten Anfang mit dabei? Oder habe die als es Git gab neu angefangen?

Wenn deine SSD so klein ist, dann hast du mein Mitleid.
Nein, brauchst du nicht. Sie ist natürlich größer, aber deutlich endlich. Es ist ja nicht nur der Teil der aus der Versionsverwaltung kommt. Da liegt, wenn man eine Arbeitskopie benutzt, ja noch mehr drin. Um mal par Zahlen zu nennen: meine aktuelle Arbeitskopie hat ohne Temp-Verzeichnisse (dort lieg aber auch nur Müll) und die erstellten Setups 9,1GB, neu ausgecheckt 4,5GB und die Repos auf dem Server 1,1GB. Wirklich hilfreich sind die Zahlen jetzt nicht, da es sehr viele große Externals aus dem Internet dabei sind.

Nervig ist es höchstens, wenn man sehr langsames Internet oder eine Volumenbeschränkung hat.
Um die Zeit für das erste Auschecken und das dafür benötigte Datenvolumen geht es mir nicht.

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.
Das kannte ich nicht. Ist wohl zwischen den vielen Konsolenbildchen untergegangen. Ach und deswegen ist das Auschecken bei Git so kompliziert. Muss ich mal googlen. Bei einigem aus dem Internet braucht man die Historie 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.
Ja, ich schlucke ja diese bitter Pille auch, wenn andere es akzeptieren, dass es ein Nachteil ist und dies fleißig bei ihren Empfehlungen mitteilen. Heißt ja nicht, das man nicht mit einem Nachteil leben 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.
Stimmt wohl nicht. Habe gerade mal nachgeschaut. Jcl mit Git ausgecheckt ist ca. 1,5 mal so groß wie mit SVN ausgecheckt (jeweils mit Standarteinstellungen, soweit ich da keinen Fehler gemacht habe). Mercurial kann ich natürlich nicht beurteilen. Darum ging es mir auch nicht.

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.
Bei Git wird nach meinem Kenntnisstand für die von dir erwähnte Nummer ein Hash-Algorithmus benutzt. Ich kenne jetzt nicht den Genauen Wert, aber denke der wirft 128 Bit raus. Wie viel von diesen Bits muss ich heute angeben, damit der noch in 10, 20 Jahren sicher eindeutig ist? Richtig alle! Auch bekommt man diese Nummer nicht in die Versionsinformationen der Exe, welche von Windows standardmäßig angezeigt wird. Und dann erkläre mal bitte einem Kunden, das heute eine kleinere Zahl neuer bedeutet und morgen eine Größere. Wünsche dir dabei viel Spaß. Ich persönlich kann die Ausgaben von Hash-Algorithmen nicht mal am Telefon fehlerfrei nebenbei rüberbringen, geschweige denn mir merken. Und das soll ein Kunde können. Niemals. Manche kommen ja teilweise schon bei vierstelligen Zahlen durcheinander.
Mit freundlichen Grüßen, einbeliebigername.
  Mit Zitat antworten Zitat