AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Werkzeuge Subversion und VisualSVN für Ein-Mann-Entwicklung
Thema durchsuchen
Ansicht
Themen-Optionen

Subversion und VisualSVN für Ein-Mann-Entwicklung

Ein Thema von Harry Stahl · begonnen am 5. Nov 2016 · letzter Beitrag vom 14. Nov 2016
Antwort Antwort
Seite 1 von 2  1 2      
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#1

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

  Alt 7. Nov 2016, 13:56
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.

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.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.742 Beiträge
 
Delphi 12 Athens
 
#2

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

  Alt 7. Nov 2016, 14:08
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Daniel
(Co-Admin)

Registriert seit: 30. Mai 2002
Ort: Hamburg
13.920 Beiträge
 
Delphi 10.4 Sydney
 
#3

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

  Alt 7. Nov 2016, 14:16
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.
Daniel R. Wolf
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.814 Beiträge
 
Delphi 12 Athens
 
#4

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

  Alt 7. Nov 2016, 14:17
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
Oliver
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.516 Beiträge
 
Delphi 12 Athens
 
#5

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

  Alt 7. Nov 2016, 14:33
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)
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu ( 7. Nov 2016 um 14:39 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von RWarnecke
RWarnecke

Registriert seit: 31. Dez 2004
Ort: Stuttgart
4.408 Beiträge
 
Delphi XE8 Enterprise
 
#6

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

  Alt 7. Nov 2016, 16:17
Hallo zusammen,

ich habe nicht alles gelesen. Aber ich gebe meinen Senf auch noch dazu. Ich benutze seit ca. 2,5 Jahren Git. Meine Repositories liegen auf zwei Servern. Der eine Server ist mein Produktionsserver und der zweite Server nur ein Backup, wo ich gelegentlich einen Push gegen absetze, damit dieser wieder auf dem aktuellen Stand ist. Alle Repositories werden so konfiguriert, dass beide Server beim Push oder Commit ausgewählt werden können. Beide Server sind mit Ubuntu installiert. Auf meinem Produktionsserver liegt auch noch ein Apache Webserver der einen Bugtracker beherbergt. Dieser Bugtracker kommuniziert ebenfalls mit den GIT-Repositories und ich kann jeden Commit einem Ticket zuweisen und auch das Ticket schließen. Dazu sind lediglich ein paar Schlüsselwörter notwendig, die ich an den Anfang der Commit-Bemerkung setze. Somit kann ich jederzeit nachvollziehen, was ich wie und wann geändert habe zu welchem Ticket.

Als Client benutze ich unter macOS das Programm SourceTree, welches es ebenfalls für Windows. Das Tool ist übersichtlich und sehr leicht zu erlernen.

Das beste daran ist, die ganze Software hat mich keinen Cent gekostet. Ich zahle lediglich nur meine Gebühr für meinen Produktionsserver der bei einem Anbieter steht.
Rolf Warnecke
App4Mission
  Mit Zitat antworten Zitat
Benutzerbild von sh17
sh17

Registriert seit: 26. Okt 2005
Ort: Radebeul
1.687 Beiträge
 
Delphi 11 Alexandria
 
#7

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

  Alt 7. Nov 2016, 17:10
@RWarnecke welchen Bugtracker nimmst Du?

Alternativ zu einem Server - Man kann git auf einem Synology NAS aktivieren und dieses als remote seinen lokalen repos für gelegentliche pushs hinzufügen.
Sven Harazim
--
  Mit Zitat antworten Zitat
Benutzerbild von RWarnecke
RWarnecke

Registriert seit: 31. Dez 2004
Ort: Stuttgart
4.408 Beiträge
 
Delphi XE8 Enterprise
 
#8

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

  Alt 7. Nov 2016, 18:17
@RWarnecke welchen Bugtracker nimmst Du?
Den Mantis Bugtracker mit den folgenden Plugins :
  • VCS Basisintegration 1.3.1
  • GitHub Integration 1.3.0
  • GitLab Integration 1.0.3
  • Gitweb Integration 0.18
  • Cgit Integration 0.16

Das erste Plugin ist das Hauptplugin. Die restlichen 4 Plugins sind optional und müssen für die entsprechende Variante hinzugefügt werden. Ich selber benutze das Gitweb-Plugin. Das Github ist nur für Repositories auf GitHub.com und das GitLab habe ich garnicht nicht ausprobiert.
Rolf Warnecke
App4Mission
  Mit Zitat antworten Zitat
einbeliebigername

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

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
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
10.047 Beiträge
 
Delphi 12 Athens
 
#10

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

  Alt 8. Nov 2016, 05:28
Und da meine ich im Falle Git dieses alles ist eine Datei-Konzept (müsste heut alles ist ein Objekt sein)
Also ich habe im Repository Dateien liegen, keine Objekte. Wie du das meinst, kann ich gerade nicht nachvollziehen.

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.
Sowohl bei SVN als auch bei Git gibt es ein Konsoleninterface und diverse GUIs. Ohne eine GUI wie TortoiseSVN ist SVN genauso konsolenbasiert.
Der Unterschied ist nur, dass du bei SVN deutlich weniger Funktionen hast, so dass die GUIs diese gut abdecken können, während bei Git viele zusätzlichen (!) Funktionen nicht über die GUI funktionieren, weil es einfach zu viele sind.

Beispiel commit, das es ja bei beiden gibt, wenn auch mit anderen Auswirkungen:
SVN:
Zitat:
svn commit
--changelist ARG
--depth ARG
--editor-cmd ARG
--encoding ENC
--file (-F) FILE
--force-log
--keep-changelists
--message (-m) TEXT
--no-unlock
--quiet (-q)
--targets FILENAME
--with-revprop ARG
Git:
Zitat:
git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
[--dry-run] [(-c | -C | --fixup | --squash) <commit>]
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--[no-]status]
[-i | -o] [-S[<keyid>]] [--] [<file>…​]
Sebastian Jänicke
AppCentral
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:06 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz