Subversion und VisualSVN für Ein-Mann-Entwicklung

[mse1]

Ich habe nicht den ganzen Thread gelesen, bin aber platt, dass es möglich sein soll ohne Versionskontrolle professionell Software zu entwickeln. Meiner Meinung nach ist auch für das kleinste Hobbyprojekt die Verwendung von Git oder einem anderen tauglichen VCS eine grosse Erleichterung. SVN ist eher nicht tauglich IMHO...
Für Git gibt es das in Free Pascal geschriebene MSEgit Frontend. Das habe ich gemacht, um ein Werkzeug zu erhalten, welches für meine Aufgaben das Maximum an Produktivität und Bequemlichkeit bietet und da alle erhältlichen GUIs meine Wünsche nicht befriedigen konnten.
Ein geändertes Projekt sieht dann z.B. aus wie "modified.png". Mit 'git'-'Commit/Stage/Unstage all (Ctrl+O)' kann der Projektstand in einem Schnappschuss festgehalten werden ("commit.png").
Jeder Projektzustand erhält einen zugeordneten Hashwert (SHA,Quersumme), welche zusammen mit dem Hashwert des Vorgängerzustandes abgelegt wird. Im Beispiel ist der SHA f9870430c6b809667e418748a2c9b1f13828651c, der des Vorgängers ('Parent') 94d840349de35a917a2688865614781a8fdf3cd4 ("committed.png"), dabei kann man die Änderungen nochmals in aller Ruhe überprüfen.
Die gesamte Kette der Projektzustände ist im Projektverzeichnis im Unterverzeichnis ".git" abgelegt; es kann jeder beliebige Zustand aus dem ".git" in das Projektverzeichnis zurückgeholt werden.
Wenn man also z.B. den Verdacht hat, mit der letzten Änderung einen Bock geschossen zu haben, kann man durch Auswählen einer Zeile im Log und RightClick-'Checkout' ein früherer Zustand zurückholen.
Zustände können Namen erhalten. Eine Zusammenhängende Zustandskette mit Namen nennt man Branch. Es gibt Möglichkeiten um Änderungen von einer Branch in andere Branch zu Übertragen.
Zustände können auch in andere git Repositories übertragen werden (push) oder von anderen Repositories ins Projekt-git-Archiv geholt werden (fetch). Die grünen Pfeile in "committed.pdf" bezeichnen Dateien, welche noch nicht in das Aktuelle remote-git-Repository übertragen wurden.
Viele meiner Projekte sind in GitLab öffentlich gemacht:
https://gitlab.com/groups/mseide-msegui
Für interne Projekte verwende ich als Backup und Netzwerk Repository Gitolite
http://gitolite.com/gitolite/index.html
MSEgit gibt es hier:
https://sourceforge.net/projects/mse.../files/msegit/
das Projekt ist hier:
https://gitlab.com/mseide-msegui/mse...r/tools/msegit

[jaenicke]

Zitat:

Zitat von mse1 (Beitrag 1352748)

Ein geändertes Projekt sieht dann z.B. aus wie "modified.png". Mit 'git'-'Commit/Stage/Unstage all (Ctrl+O)' kann der Projektstand in einem Schnappschuss festgehalten werden ("commit.png").

Die Ansichten finde ich total unübersichtlich. Dass man bei solchen Fenstern als VCS-Einsteiger keine Lust mehr hat, kann ich absolut nachvollziehen. Da habe ich selbst ja auch schon keine Lust mehr mir das anzuschauen. ;-)

Da finde ich die Fenster und Ansichten aus meinen Screenshots mit TortoiseGit deutlich besser:
http://www.entwickler-ecke.de/topic_...it_115462.html

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Finde ich sehr Schwach dieses Argument. Wenn etwas plötzlich nicht mehr funktioniert, weiß man in der Regel wo man kürzlich dran gearbeitet hat.

Das hilft dir aber auch nur bedingt, wenn du nicht einfach die thematischen einzelnen Änderungen durchgehen kannst, sondern lediglich mehrere Versionsstände auf Dateiebene miteinander vergleichen kannst.
Natürlich kann man auch so vergleichen, es ist aber ein Vielfaches umständlicher.

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Auch das sollte einem normalerweise nicht passieren und ist mir in mittlerweile 9 Jahren nicht passiert.

Zumindest hast du es nicht bemerkt. Da du beim Abschicken der Änderungen keine Prüfung durchführst, kannst du es ja gar nicht merken, außer wenn du irgendwann merkst, dass etwas nicht mehr geht. Da du die letzten Änderungen an der Stelle aber auch wiederum dann später gar nicht zur Verfügung hast, kannst du auch wiederum nicht so einfach feststellen, dass das Problem bei einer bestimmten Änderung eingebaut wurde.

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Meine ZIP-Archive sind auch an einer definierten Stelle =)

Das Argument passt bei dir nicht, nein.

Zitat:

Zitat von Jim Carrey (Beitrag 1352746)

Ebenfalls ein schwaches Argument wie ich finde. Man sollte seinen Code schon kennen.

Das kommt eben auf die Projektgröße an. Weder bei meinen beruflichen noch bei meinen privaten Projekten kann ich den Code auswendig kennen, weil der Quelltext schlicht zu umfangreich ist. Und schon gar nicht Jahre später noch wissen was wie läuft.

[Harry Stahl]

Zitat:

Zitat von jaenicke (Beitrag 1352744)

Ich habe hier zu Git mal eine kurze Einführung mit Screenshots geschrieben (wirklich nur kurz zum Einstieg):
http://www.entwickler-ecke.de/topic_...it_115462.html
Zum Server bin ich leider noch nicht gekommen...

Danke, das ist sehr hilfreich.:thumb:

Auch Dein Tutorial zu Subversion hätte mir eine Menge Raterei erspart, wenn ich es schon gekannt hätte...

In Fakt sieht es aber so aus, als ob alle Leute, die Versionsverwaltung machen, NICHT die Integration in Delphi verwenden, um die Änderungen zu posten oder zu holen, oder sehe ich das falsch?

[mse1]

Zitat:

Zitat von jaenicke (Beitrag 1352749)

Die Ansichten finde ich total unübersichtlich.

Selbstverständlich kann man sich bei MSEgit die Fenster einrichten wie man will. Wie hättest du es denn gerne?

[mse1]

Zitat:

Zitat von Harry Stahl (Beitrag 1352750)

In Fakt sieht es aber so aus, als ob alle Leute, die Versionsverwaltung machen, NICHT die Integration in Delphi verwenden, um die Änderungen zu posten oder zu holen, oder sehe ich das falsch?

Ich finde die Integration alles und jedes in eine IDE keine gute Idee. Dadurch entsteht ein unhandliches fehleranfälliges Monster das so kompliziert zu programmieren ist, dass man bei der Qualität, Funktionsumfang und Usability zwangsläufig Abstriche machen muss.

[Harry Stahl]

Doppelter Post (gelöscht)

[Frickler]

Ich nutze jetzt seit ca. 10 Jahren Subversion in Form von TortoiseSVN. Davor habe ich ZIP-Archive gemacht. Was ich als riesigen Vorteil gegenüber den ZIP-Archiven sehen, ist, dass ich beim Einchecken von Änderungen einen Kommentar hinterlegen kann (z.B. sowas wie "Anforderung #4711 - Schriftart in den Buttons fett" oder so). So kann ich auch noch Jahre später sehen, was gemacht wurde, ohne jedesmal in die Diffs sehen zu müssen.

Meine Struktur ist so: jede Projektgruppe ein Archiv, und zusätzlich ein Archiv für einen "LIB"-Ordner, in dem gemeinsame Bibliotheken liegen. Jede Projektgruppe besteht aus einzelnen Ordnern für die Unterprojekte, und auch dort einem "LIB"-Ordner für alles, was für alle jeweiligen Unterprojekte gemeinsam benötigt wird (z.B. auch fr3-Reportdateien).

Die ganze Entwicklung läuft auf 2 peer-to-peer vernetzten Rechnern, ein Server und ein "VM-Server" mit VMs für jede Entwicklungsumgebung und für jeden Testrechner.

[Jim Carrey]

Zitat:

Natürlich kann man auch so vergleichen, es ist aber ein Vielfaches umständlicher.

Da ist garantiert was dran und das bestreite ich nicht.

Zitat:

Das kommt eben auf die Projektgröße an. Weder bei meinen beruflichen noch bei meinen privaten Projekten kann ich den Code auswendig kennen, weil der Quelltext schlicht zu umfangreich ist. Und schon gar nicht Jahre später noch wissen was wie läuft.

Mein aktuelles Projekt hat derzeit ohne Leerzeilen 56.000 Zeilen.
Das ist nicht sonderlich viel aber ich weiß immer ganz genau was ich wo finde.

Zitat:

Was ich als riesigen Vorteil gegenüber den ZIP-Archiven sehen, ist, dass ich beim Einchecken von Änderungen einen Kommentar hinterlegen kann (z.B. sowas wie "Anforderung #4711 - Schriftart in den Buttons fett" oder so). So kann ich auch noch Jahre später sehen, was gemacht wurde, ohne jedesmal in die Diffs sehen zu müssen.

ZIP-Archive können auch Kommentare enthalten.

[Valle]

Werden noch Leute für die Statistik benötigt? :stupid:

Ich lege ebenso für jedes Projekt, bei dem ich davon ausgehe dass ich es morgen nochmal anfassen werde, ein Git Repository an. Ein paar veröffentliche ich auch auf Github. Mit SVN braucht man heute nicht mehr anfangen. Ich würde empfehlen sich für Git (oder gern auch Mercurial) mal ein paar Tage lang mit der Konsole zu befassen. Wenn einem die Konsole dann immernoch nicht zusagt, kann man ja wechseln. Ich bin mit der Konsole ein vielfaches schneller und verstehe auch besser was Git da tut.

Mit Zip-Dateien entwickeln... kann man machen. ( :zwinker: ) Aber falls mal jemand mit Versionierung überhaupt erst anfängt, würde ich empfehlen einfach eine fertige Lösung für das Jahrzehnte alte Problem zu verwenden und sich in Git einzuarbeiten. Solange man das nicht einfach "schon immer so macht", sehe ich in Zips keine weiteren Vorteile.

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1352750)

In Fakt sieht es aber so aus, als ob alle Leute, die Versionsverwaltung machen, NICHT die Integration in Delphi verwenden, um die Änderungen zu posten oder zu holen, oder sehe ich das falsch?

Das haben wir versucht, eigentlich wäre die sehr praktisch. Neue Units automatisch ins Repository usw., an jeder Zeile die letzte Änderung sehen, ...

Wenn das alles geklappt hätte, hätten wir auch einen eigenen Commit-Dialog gebaut, der die für uns nötigen Angaben (Ticketnummer usw.) direkt in das passende Format bringt, damit unsere Build Tools diese extrahieren können.

Aber leider gab es immer wieder mal Schutzverletzungen, nach denen wir dann manuell Cleanups machen mussten. Deshalb haben wir es am Ende aufgegeben...

Wir benutzen jetzt TortoiseSVN und TortoiseGit mit einem externen Tool um den Committext zu erstellen. Den kopieren wir dann einfach hinein.

[Harry Stahl]

Also, ich habe jetzt mal ein wenig (bzw. ein wenig mehr) an einem Projekt gearbeitet (noch weiterhin mit Subversion) und das ein- und auschecken über die in Delphi integrierte Lösung gemacht.

Soweit hat das eigentlich ganz gut funktioniert. Ist schon toll, wenn ich an einem Rechner gearbeitet habe und öffne das Projekt an einem anderen Rechner, wähle dann per rechten Mausklick auf den Projektnamen den Kontextbefehl "Subversion", "Aktualisieren", "Aus Repository Stammverzeichnis" und schon wird mein Projekt auf den aktuellen Stand gebracht.

Das ist schon mal viel einfacher, als Dateien zwischen den Rechnern über das Netzwerk oder sonstwie zu kopieren.

Und da man sich auch die Unterschiede mit dem eingebundenen Beyond-Compare ansehen kann (das sich im About-Dialog lustigerweise mit "RAD-Studio XE9-Edition" meldet), finde ich das doch alles recht komfortabel.

Was mir noch nicht gelungen ist: Externals einzubinden, also Dateien, die nicht im Projektverzeichnis oder in einem Unterverzeichnis davon liegen.

Falls jemand Subversion nutzt, wäre ich für einen Tipp dankbar.

(Auch wenn jetzt viele gesagt haben, nehm direkt GIT oder Mercurial, ich will die Subversion-Nutzung zumindest einmal von vorn bis hinten bei einem Projekt durchziehen, damit ich einen vollständigen Eindruck bekomme, nur dann werde ich ja auch in der Lage zu sein, zu vergleichen und zu bewerten, was ich evtl. alternativ besser finde)

Noch eine weitere, für mich wichtige Frage: Für meine Lazarus-Pascal-Projekte wäre es natürlich auch toll, ein Versionsverwaltungssystem zu verwenden (ich arbeite dann mit dem jeweiligen Lazarus auf Windows / dem Mac / Linux). Hat jemand unter diesem Aspekt evtl. auch Erfahrungen gemacht, welche Versionsverwaltung hier zu empfehlen wäre?

Zwischenfazit von mir:
Generell habe ich jedoch schon mal den Eindruck, dass die Versionsverwaltung etwas ist, was ich auf jeden Fall hinzu nehmen werde. Man kann zwar auch ohne Versionsverwaltung professionell Software entwickeln, aber ich denke es könnte mir die Sache doch erheblich erleichtern. Gerade, wenn man feststellt, dass plötzlich etwas nicht mehr funktioniert, kann man sehr leicht vergleichen, was in den einzelnen Revisionen geändert wurde und so schnell die Ursache ermitteln.

Und ja, auch für eine einzelne Person ist das eine Hilfe.

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1352813)

Was mir noch nicht gelungen ist: Externals einzubinden, also Dateien, die nicht im Projektverzeichnis oder in einem Unterverzeichnis davon liegen.

Wie du das mit Tortoise machst, kannst du hier in der Doku nachlesen:
https://tortoisesvn.net/docs/release...externals.html

Zitat:

Zitat von Harry Stahl (Beitrag 1352813)

Noch eine weitere, für mich wichtige Frage: Für meine Lazarus-Pascal-Projekte wäre es natürlich auch toll, ein Versionsverwaltungssystem zu verwenden (ich arbeite dann mit dem jeweiligen Lazarus auf Windows / dem Mac / Linux). Hat jemand unter diesem Aspekt evtl. auch Erfahrungen gemacht, welche Versionsverwaltung hier zu empfehlen wäre?

Alle diskutierten VCS sind crossplatform, SVN, Git und Mercurial. Auf Serverseite kenne ich nur die Windows-Server VisualSVN Server und Bonobo Git Server, aber es gibt auch und vor allem Server für andere Plattformen. Auf Clientseite gibt es diverse Clients außerhalb von Windows, aber kein Tortoise. Mittlerweile gibt es aber auch für Linux und andere Plattformen graphisch ansprechende Clients, die man sehr angenehm nutzen kann. Paradoxerweise kosten die meisten allerdings anders als Tortoise für Windows etwas. Angesichts der kostenlosen Alternativen, die ich kenne, würde ich aber in die Richtung tendieren.

Alternativ funktioniert die reine Git-Kommandozeile auf allen Plattformen gleich, aber ich persönlich brauche damit so extrem viel mehr Zeit, dass ich nicht dazu raten kann.

[warschonweg]

Wobei Git im Gegensatz zu Mercurial unter Windows nur via Emulation funktioniert.

[einbeliebigername]

Hallo,

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

4. Nutzt das auch jemand von Euch als Einzelperson, welche Erfahrungen habt ihr damit gemacht?

Ja, sowohl im Team als auch für eigene private Projekte. Benutze nur noch SVN. Mittlerweile auch für dinge die nichts mit Programmieren zu tun haben.

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

Und zwar unter dem Aspekt, dass ich im Netzwerk mal an unterschiedlichen PC's die gleichen Projekte (zu Testzwecken) verwalte, bzw. von Unterwegs (auf Reisen) mit einem Notebook vor Ort gerne mal ein Projekt weiter bearbeiten möchte, so dass ich dann nach Rückkehr an meinem Hauptentwicklungs-PC die Änderungen aus dem Repository übernehmen kann.

Ist bei mir auch so. Komisch, ist das noch nicht der Vorschlag kam, alles nur noch mit dem Notebook und einer Dockingstation zumachen, denn dann würde man ja ein Versionsverwaltungssystem nicht benötigen. Es soll ja noch Leute geben die einen richtigen Rechner zum Entwickeln benötigen. Sei es weil Hardware drinsteckt die einfach nicht in ein Notebook passt oder der Kunde genau das gleiche System einsetzt und er sich bestimmt nicht ein Notebook ins Rack stellt.

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

Habe mir dazu auf meinem Strato-Webserver (Windows 2012 Server) das Programm VisualSVN eingerichtet und mir dort Repositories angelegt.

Mir persönlich wäre das zu unsicher. Habe lieber alles zu Hause. Lieber wird mein Sourcecode durch Brand vernichtet, als das jemand anderes ihn in die Finger bekommt. Und dafür habe ich so ein selbstgebauten Windows Home Server.

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

Sollte ich (obwohl ich ja nur eine Person bin) mehrere Benutzer einrichten und diese Identitäten dann jeweils von den anderen PC's aus nutzen?
Oder nur einen Benutzer?

Wie du magst. Ich habe auf meinem SVN-Server nur eine Identität für mich (mir reichen schon die vielen im Kopf :lol:).

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

2. Dann eine Frage zu den globalen / geteilten Units, die in unterschiedlichen Projekten verwaltet werden. Wie bindet man die richtigerweise ein?

Das ist ein Schweres Thema. Es gibt da mehrere Möglichkeiten.

A: So ein Repository ist je wie ein Verzeichnis. Man kann alle Projekte und die gemeinsam verwendeten Sachen in ein Einziges einchecken. Vorteil die Relativen Pfade zwischen den Projekten und dem Gemeinsamen sind immer gleich. Nachteil es gibt nur eine Revisionsnummer (jedenfalls bei SVN) und sollte es mal einen Fehler im Repository geben sind mitunter alle Projekte betroffen.

B: Jedes Projekt und somit auch das Gemeinsame bekommen ihr eigenes Repository. Nachteil man muss auf die Abhängigkeiten zwischen den Projekten und somit zwischen den Repositorys aufpassen. Dazu kann man bei SVN die Eigenschaft svn:externals benutzen. Entweder man macht sich ein Ober-Repository und hängt mittels svn:externals alle anderen dort rein. Dann würde man auf einem anderen Gerät nur das Ober-Repository auschecken und alle anderen würden mit der richtigen Struktur automatisch mit auf der Platte landen. Oder man hängt das Gemeinsame per svn:externals in jedem Projekt ein. Hat beides seine Vor- und Nachteile. Bei dem einen sind Änderungen am Gemeinsamen sofort bei allen Projekten verfügbar und beim anderen kann man das Gemeinsame bei verschiedenen Projekten in unterschiedlichen Versionen verwenden.

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

Das Subversionssystem übernimmt offensichtlich nur alle Dateien aus dem Projektverzeichnis und aus den

Ja. Die Versionsverwaltungssysteme, welche ich mir bis jetzt angesehen habe, arbeiten immer auf einem Verzeichnis. Was außerhalb dieses liegt, liegt außerhalb des Repositorys.

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

3. Prinzipiell würde mich auch das Thema "Branches" interessieren. Mir geht es hin und wieder schon mal so, dass ich ein Programm in eine bestimmte Richtung entwickle, dann aber einen großen Teil oder fast alles wieder verwerfe und dann ist es manchmal recht umständlich wieder auf die gewünschte Ausgangsversion zurückzukommen, bzw. vielleicht möchte man ja einen Teil der Arbeit in die alte Ausgangsversion übernehmen.

Wie macht man das? Wie sage ich Delphi, dass die aktuelle Arbeit jetzt Teil eines variablen Zweigs sein soll? Indem ich es erneut in den Braches-Ordner poste? Muss ich mir dort selber Unterordner anlegen?

Wie und ob das mit Delphi geht, habe ich noch nicht getestet. Ich kann dir da nur TortoiseSVN empfehlen. Aber die nötige Verzeichnisstruktur Trunk, Tags und Branches hast du in den Repositorys angelegt?

Zitat:

Zitat von Namenloser (Beitrag 1352694)

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

ob ich nicht auch als Einzelperson von der Subversionsverwaltung profitieren kann.

Auf jeden Fall! Wie hast du es denn bisher ohne ausgehalten? :shock:

Aber tu dir bitte einen Gefallen: Nimm gleich Git, nicht Subversion.

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.

Zitat:

Zitat von ThomasBab (Beitrag 1352721)

Ich würde _immer_ über die Konsole arbeiten, damit ich die Kontrolle über die versionierten Dateien habe.

Konsole und Kontrolle schließen sich doch wegen mangelnder Übersichtlichkeit aus. Keine Bildchen, keine Kontextsensitivität, fängt schon damit an das die Konsole keine Informationen von sich aus herausgibt.

Zitat:

Zitat von ThomasBab (Beitrag 1352721)

Zu den versionierten Dateien können ja auch Dateien gehören, die überhaupt keinen direkten Bezug zum Source-Code habe: Doku, Beispiel-Daten etc.

Da hilft aber auch keine Konsole. Da hilft nur Tortoise..., und das noch nicht mal vollständig.

Zitat:

Zitat von Harry Stahl (Beitrag 1352813)

Was mir noch nicht gelungen ist: Externals einzubinden, also Dateien, die nicht im Projektverzeichnis oder in einem Unterverzeichnis davon liegen.

Falls jemand Subversion nutzt, wäre ich für einen Tipp dankbar.

Auch Externals landen in dem Verzeichnis des Repositorys. Aber noch mal den Tipp, installier dir TortoiseSVN. Das ist wesentlich übersichtlicher. Und dann siehe oben.

Zitat:

Zitat von Harry Stahl (Beitrag 1352813)

Und ja, auch für eine einzelne Person ist das eine Hilfe.

Ja, auf jeden Fall.

PS: Ist die Mehrzahl von Repository in einem deutschen Text Repositories oder wie Google meint Repositorys?

[warschonweg]

Repositorys natürlich. Im Deutschen gelten englische Deklinationsregeln nicht.

[einbeliebigername]

[OT]

Zitat:

Zitat von warschonweg (Beitrag 1352823)

Repositorys natürlich. Im Deutschen gelten englische Deklinationsregeln nicht.

Du hast wohl Recht. Mir fehlte dazu aber noch ein Beweis. Das wurde wohl mit der Rechtschreibreform geändert (http://www.neue-rechtschreibung.net/...wortern-auf-y/).[/OT]

[mse1]

Zitat:

Zitat von einbeliebigername (Beitrag 1352822)

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

3. Prinzipiell würde mich auch das Thema "Branches" interessieren. Mir geht es hin und wieder schon mal so, dass ich ein Programm in eine bestimmte Richtung entwickle, dann aber einen großen Teil oder fast alles wieder verwerfe und dann ist es manchmal recht umständlich wieder auf die gewünschte Ausgangsversion zurückzukommen, bzw. vielleicht möchte man ja einen Teil der Arbeit in die alte Ausgangsversion übernehmen.

Wie macht man das? Wie sage ich Delphi, dass die aktuelle Arbeit jetzt Teil eines variablen Zweigs sein soll? Indem ich es erneut in den Braches-Ordner poste? Muss ich mir dort selber Unterordner anlegen?

Wie und ob das mit Delphi geht, habe ich noch nicht getestet. Ich kann dir da nur TortoiseSVN empfehlen. Aber die nötige Verzeichnisstruktur Trunk, Tags und Branches hast du in den Repositories angelegt?

Zitat:

Zitat von Namenloser (Beitrag 1352694)

Zitat:

Zitat von Harry Stahl (Beitrag 1352689)

ob ich nicht auch als Einzelperson von der Subversionsverwaltung profitieren kann.

Auf jeden Fall! Wie hast du es denn bisher ohne ausgehalten? :shock:

Aber tu dir bitte einen Gefallen: Nimm gleich Git, nicht Subversion.

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.

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

[ThomasBab]

Hallo!

Hier sind mir gerade noch zwei Links begegnet:

http://t3n.de/news/eigentlich-github-472886/

http://t3n.de/news/github-fuer-einst...hritte-762760/

[Sherlock]

Und jetzt noch eine Portion Senf von mir (Mercurial Anwender):
Branching mit SVN, ist der einhelligen Meinung aller Beteiligten nach suboptimal. Nicht nur darum hat man andere Versionsverwaltungen erfunden (und nein, git oder hg sind nicht älter als SVN, eher umgekehrt). Branching ist mit den modernen Versionskontrollsystemen mit Null aufwand verbunden, da jeder Commit prinzipbedingt innerhalb eines Branches erfolgt. 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. 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

Ein Tutorial, daß mir die hg Welt näher gebracht hatte, weil ich von JEDI VCS weg wollte/musste ist http://hginit.com/. Interessanterweise ein konsolenbasiertes Tutorial. Das bringt dann zweierlei: Es nimmt die Angst vor der Konsole und zeigt wie einfach die Bedienung dann doch ist. Wenn man danach auf TortoiseHg setzt, hat man überhaupt keine Probleme und weiss sich im Zweifelsfall auf der Konsole zu helfen.

Sherlock

[Bbommel]

Hallo Harry,

na, wenn so viele etwas dazu zu sagen haben, dann will ich auch mal. :)

Ich nutze seit einigen Jahren SVN. SVN statt Git letztlich deshalb, weil ich damit so ein bis zwei Jährchen angefangen habe, bevor plötzlich alle meinten, dass ein zentrales VCS jetzt veraltet sei und man auf jeden Fall Git benutzen muss. Da SVN allerdings alles kann, was ich brauche und ich auch mit Tags und Branches nie Probleme hatte, bin ich dabei geblieben und damit bis heute eigentlich sehr zufrieden.

Was ich aber noch loswerden wollte, weil du danach gefragt hattest und es ansonsten bisher eher in Nebensätzen angeklungen ist: Ich benutze nicht die in Delphi eingebaute SVN-Integration, sondern den Windows-Client "TortoiseSVN". Das hat den Vorteil, dass das Tool einfach noch mehr kann als die Delphi-Integration und vor allem, dass du im Netz viel mehr Material dazu findest, falls doch mal etwas unklar ist. Vor allem bringt TortoiseSVN schon selbst eine sehr gute Dokumentation mit.

Die von dir noch offene Frage zur Einbindung von externen Dateien in ein Projekt wird z.B. hier in der Doku behandelt:
https://tortoisesvn.net/docs/release...externals.html

Bis denn
Bommel

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

[jaenicke]

Zitat:

Zitat von einbeliebigername (Beitrag 1352867)

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:

Zitat von jaenicke (Beitrag 1352872)

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:

Zitat von jaenicke (Beitrag 1352872)

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:

Zitat von einbeliebigername (Beitrag 1352848)

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.

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:

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.

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:

Zitat von einbeliebigername (Beitrag 1352876)

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:

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.

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

Zitat:

Zitat von einbeliebigername (Beitrag 1352848)

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.

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:

Zitat von Namenloser (Beitrag 1352881)

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? :gruebel:)

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)