Privaten SVN Server einrichten!

[Phoenix]

Zitat:

Zitat von Sherlock (Beitrag 1233364)

ICh habe mich übrigens für Mercurial entschieden. Möge der Glaubenskrieg beginnen (SVN hat eh von Anfang an keine Chance gehabt).

Ich glaub so einen GLaubenskrieg wird das nie auslösen ;-)

Mercurial war von Anfang an etwas besser im Tooling (insb. auf Windows). Da hat Git aber inzwischen gut aufgeholt. Vom Featureset ist Git ein klein wenig besser, aber das sind Edge-Cases, die man im normalen Entwicklungsalltag normalerweise nicht spürt.

Mit Kiln gibt es inzwischen schon Server, die sogar beides können, und bei denen der eigentlich genutzte Client (ob jetzt Git oder Hg) auch vollkommen wurscht ist. Ud wenn man Kiln nicht kaufen mag, dann kann mit automatisierten Git/Hg-Bridges das auch selber hinbasteln.

Und wenn man z.B. Sourcetree als Client nutzt, kann man damit auch Git und Hg Repos verwenden.

[Lemmy]

Guten Morgen,

@Mavarik:

Zitat:

Zitat von Mavarik (Beitrag 1233331)

Der Grund ist... Ich werde nach und nach unser Projekt auf Unicode umstellen. Bin gespannt wie gut das klappt, die Änderungen
der produktiven Version von Zeit zu Zeit in die auf Unicode geändert Version zu Mergen. (Das soll ja gehen, oder)

auch wenn ich manchen Aussagen hier nicht zustimme: Lass in diesem (Anwendungs)Fall die Finger von svn. Das Merging in git/Mercirual ist besser.

Grüße

[sh17]

Hör auf Elvis :warn: :-D

[Mavarik]

Boh ey...

Jetzt hab ich mich erfolgreich Jahre lang darum gedrückt...
Jetzt hab ich das ganze Wochenende getestet um das Ganze zu verstehen...
Jetzt hab ich meine laufenden Projekte ALLE auf SVN umgestellt...
Jetzt soll ich schon wieder was neues machen...

Frei nach LW1-4 OK OK OK ich werde es mir anschauen...

Danke für Euer Feedback...

Mavarik

[Daniel]

Ja, das mag ärgerlich sein - aber umsonst war das WE gewiss nicht: Bei aller Schelte, die SVN einstecken muss, die Grundprinzipien von Versionsverwaltungen sind geblieben. Wenn Du also verinnerlicht hast, wie man mit Branches und derlei arbeitet, geht es bei einer Umstellung auf ein neues System lediglich um die Frage des "Wie geht das dort?" und nicht mehr um das "Was ist das überhaupt?".

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1233435)

Ja, das mag ärgerlich sein - aber umsonst war das WE gewiss nicht: Bei aller Schelte, die SVN einstecken muss, die Grundprinzipien von Versionsverwaltungen sind geblieben. Wenn Du also verinnerlicht hast, wie man mit Branches und derlei arbeitet, geht es bei einer Umstellung auf ein neues System lediglich um die Frage des "Wie geht das dort?" und nicht mehr um das "Was ist das überhaupt?".

Gebe ich Dir Recht... Aber nur weil ich das NIE eingesetzt habe bedeutet es ja nicht, dass ich mich nicht zwischendurch mal damit beschäftigt haben... Hatte lokal auch schon einen SNV Server eingerichtet, aber nur für Datensicherung...

Aber was den nun:

Mercurial oder Git?

TortoiseHg oder SourceTree?

Mavarik

PS: Echt jetzt? Anleitung als Commandline tool?

[Mavarik]

Also... Nachdem ich mich ein bisschen eingelesen habe...

Ist ja gruselig, dass alle Anleitung für Commandozeilen sind.

Ob das Mergen so viel besser geht, bezweifele ich erst mal. Wenn zwei Leute die Parameter einer Procedure geändert haben,
kann keine Automatik das Mergen übernehmen.

Also wo soll der Vorteil zu SVN sein? Aus den Anleitungen kann ich da keinen sehen.

Und die lokale Kopie des Repository... Macht es eher schwerer den Überblick zu behalten, oder?
Nicht nur Commit sondern auch noch Push and Pull?

Und das GUI... Viele bunte Striche...

Da finde ich den Revisionsgraph von TortosieSVN übersichtlicher...

Also bisher kann mich das noch nicht überzeugen... Mal in der Praxis ein paar Tests machen...

Mavarik

[Daniel]

Wenn Du eine konkrete Stelle hast, an der in der einen Datei ein Zeichen "A" lautet und in einer anderen Datei "B", dann musst Du den Konflikt per Hand lösen.

Das Mergen wird aber oftmals dadurch lästig, weil die Versionsverwaltung die unterschiedlichen Stände nicht mehr nahtlos zusammenfügen kann und buchstäblich den Überblick verloren hat, welche Code-Abschnitte zusammengehören und wo sich Dinge einfügen ließen. Und genau da gibt es Systeme, die aufgrund der Informationsmenge, die sie vorhalten, zielsicherer ans Werk gehen können als SVN.

[Lemmy]

Zitat:

Zitat von Mavarik (Beitrag 1233472)

Ist ja gruselig, dass alle Anleitung für Commandozeilen sind.

daher finde ich die Kommandozeile "einfacher", weil du da zig Anleitungen findest

Zitat:

Zitat von Mavarik (Beitrag 1233472)

Ob das Mergen so viel besser geht, bezweifele ich erst mal. Wenn zwei Leute die Parameter einer Procedure geändert haben,
kann keine Automatik das Mergen übernehmen.

ist so. Ein Beispiel:


SVN Repository, 3 Entwickler. 2 Davon hatten die gleiche Datei in Bearbeitung (pas + dfm). Der eine ändert was in einer Prozedur, der andere löscht einen Button und die dazugehörige OnClick Methode. Der Entwickler, der den Button gelöscht hat macht als erster den Commit, dann kommt der zweite daher und wie auf magische Weise ist der Button + OnCLick Event wieder da (automatischer Merge). Passiert ist mir das nachweislich mind. 2x 2006-2008 - kann sich aktuell daher schon gebessert haben, wenn die das Merging aber nicht komplett umgestellt haben ist das immer noch ein Problem - da kann git einfach mehr.

[Mavarik]

Zitat:

Zitat von Daniel (Beitrag 1233473)

Und genau da gibt es Systeme, die aufgrund der Informationsmenge, die sie vorhalten, zielsicherer ans Werk gehen können als SVN.

OK.. Verstehe... Aber ist das nicht eher ein Fall für "Bejond Compare" als für eine Entscheidung wie Files in History gespeichert werden?

Beispiel:

Ich sichere jetzt meinen Versionstand (TAG) und zwei Leute arbeiten von diesem Punkt aus weiter.

Der eine programmiert neues Zeug und behebt Bugs der andere stellt um auf Unicode... (Ändert also nahezu jede Unit)
nach 3 Monaten soll ein Merge noch funktionieren? Oder muss man zwischen durch immer wieder aktualisieren?

Bei den reinen *.pas Dateien mag das ja noch passen, aber was ist mit den DFM Files? Was ist mit Komponenten, die je nach Brache andere Properties haben? Die also je nach Branch auch jeweils neu im Delphi installiert werden müssen...

Da gibt es noch viele viele viele viele offene Fragen... Nicht nur nach dem "richtigen" Tool, sondern auch einer konformen
Arbeitsweise...

Mavarik