Subversion und VisualSVN für Ein-Mann-Entwicklung

[mse1]

Zitat von einbeliebigername:

Zitat von Harry Stahl:

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 von Namenloser:

Zitat von Harry Stahl:

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

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

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

[einbeliebigername]

Hallo,

Zitat von mse1:

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 von mse1:

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 von Sherlock:

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 von Sherlock:

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 von Sherlock:

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 von Sherlock:

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 von Sherlock:

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

Zitat von jaenicke:

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

Ist bei SVN auch so.

Zitat von jaenicke:

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

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