SVN verwenden

[braunbär]

Ich habe zur Installation des FPC Trunk Tortoise SVN heruntergeladen. Wenn ich jetzt an ein paar Dateien Änderungen mache, dann würde ich natürlich selbst auch gerne das SVN verwenden. Irgendwie scheint das aber nicht zu gehen, Tortoise SVN kennt anscheinend das FPC Trunk Verzeichnis als einen Bereich, in den das Online-Repository ausgecheckt worden ist, und bietet mir das Menü zum Export ins lokale Repository gar nicht an.

Im Notfall könnte ich natürlich für ein lokales Repository ein anderes Programm wie Git nehmen, aber eigentlich würde ich mich ungern gleich mit zwei Programmen auf einmal vertraut machen.
Eine andere Alternative wäre, die Files, an denen ich arbeite, in ein anderes Verzeichnis zu kopieren und die Files von dem anderen Verzeichnis in mein Testprojekt zu importieren. Ich fürchte nur, dass das recht fehleranfällig ist.

Wie geht man da am besten vor?

[wp_xyz]

Ich verstehe das Problem noch nicht: Willst du für ein eigenes Projekt eine Versionsverwaltung haben? Oder willst du FPC-Sourcen unter Versionskontrolle verändern?

[braunbär]

Ich möchte die FPC Sourcen unter Versionskontrolle verändern, aber ich habe ja keinen Schreibzugriff auf das Online repository, und brauche das auch gar nicht. ich möchte mein SVN lokal halten.

Aber ich habe eine Lösung, mit der ich jetzt halbwegs zufrieden bin, gefunden: Ich habe das kompette Classes VerzeichInis in das Verzeichnis meines Testprojekts kopiert und die Files aus Classes im Testprojekt durch die Kopien ersetzt, arbeite also jetzt nur mehr in meinem Testverzeichnis. Nachdem ich voraussichtlich nur in 3 FPC-Files Änderungen machen werde, wird das überschaubar bleiben. Wenn ich fertig bin, kopiere ich die veränderten Files wieder zurück.

Ich vermute, dass es eine bessere Lösung gibt. Wenn ich an mehr Dateien arbeiten würde, wäre die Vorgangsweise unbefriedigend, weil man dann wahrscheinlich leicht die Übersicht verlieren kann, welche Files der Compiler von wo nimmt. Ausserdem bekommt man nicht so leicht mit, wenn ein File, an dem man arbeitet, im online-Repository verändert worden ist. Ich kenne mich aber mit Tortoise SVN noch zu wenig aus.

[wp_xyz]

Ich denke, man könnte auch ein git aufsetzen und dort das FPC-Verzeichnis vom SVN-Online-Repository reinklonen - das wär mir aber zu kompliziert, und ich würde ähnlich vorgehen wie du.

Ausserdem bekommt man nicht so leicht mit, wenn ein File, an dem man arbeitet, im online-Repository verändert worden ist.

Das geht auch nicht automatisch, du musst nach Rechtsklick auf dem FPC-Verzeichnis "SVN Update" aufrufen.

[mschnell]

Wie geht man da am besten vor?

Du hast (natürlich) keine Schreibrechte auf das SVN Reprository von FPC.

Wenn Du SVN verwenden möchtest, musst Du Dir einen SVN Server einrichten, oder einen finden, der Dich schreiben lässt.

-Michael

[wp_xyz]

Wie geht man da am besten vor?

Wenn Du SVN verwenden möchtest, musst Du Dir einen SVN Server einrichten, oder einen finden, der Dich schreiben lässt.

Man kann allerdings auch ein lokales SVN-Repo einrichten (mit TortoiseSVN: Rechtsklick auf Verzeichnis > "TortoiseSVN" > "Create repository here")

[braunbär]

@mschnell

Ich möchte die FPC Sourcen unter Versionskontrolle verändern, aber ich habe ja keinen Schreibzugriff auf das Online repository, und brauche das auch gar nicht. ich möchte mein SVN lokal halten.

Das Problem besteht darin, ist, dass ich offenbar Dateien, die im FPC Verzeichnis liegen, von da nicht in ein lokales SVN Repository importieren kann, weil das FPC Verzeichnis von einem Online-Repository ausgecheckt worden ist, und mir das SVN hier ein ganz anderes Menü anzeigt als in Verzeichnissen, bei denen das nicht der Fall ist. Das FPC Verzeichnis scheint für TortoiseSVN fix als "Checkout-Verzeichnis" mit dem Online-Repository verknüpft zu sein.

Ein lokales Repository für mein Testverzeichnis konnte ich ohne Schwierigkeiten einrichten.

[af0815]

SVN ist einmal ein (server) gestütztes VCS. Aller ding halt nur mit 1 nen Server. Man kann den Server wechseln, geht bei Tortouise SVN mit Relocate. Das ist aber nicht für ein arbeiten mit mehreren Servern gedacht, nur zum ändern, falls der Server umzieht.

Git ist dagegen so designed das er mit mehreren Servern umgehen kann. Man kann auch SVN Repos in Git halten. Hat den VT das man zB. das FPC auf SVN lässt und den Server als Uplink verwendet um sich die Änderungen zu holen, selbst aber mit GIT und seinem Repository arbeitet. Ist gewöhnungsbedürftig, geht aber zur Not.

Wenn man schon in GIT ist, so verwendet man einen GIT_Mirror für FPC/Lazarus und hat die wenigsten Probleme.

[mschnell]

Immerhin kann man mit GitHub einen kostenlosen öffentlichen GIT Server verwenden (falls man es schaffen sollte alles korrekt einzurichten).

-Michael

[Warf]

Es gibt doch git mirrors: Link

Zum lokalen arbeiten ist Git viel besser als SVN (bzw. SVN ist dafür gar nicht geeignet). Clone dir einfach den mirror, arbeite auf einem lokalen branch (oder forke es in einem eigenen repository wenn du backups haben willst), wenn du zufrieden bist merge (lokal) in master (der sich in der zeit ja wahrscheinlich etwas geupdatet hat) und dann kannst du einen Patch gegen den vorigen commit erstellen wenn du die Änderungen öffentlich machen willst

[braunbär]

Zum lokalen arbeiten ist Git viel besser als SVN (bzw. SVN ist dafür gar nicht geeignet).

Warum? Was sind die entscheidenden Unterschiede zwischen GIT und TortoiseSVN bzw. Vorteile von GIT?
Ich möchte mir jetzt, auch für meine anderen Projekte, ein lokales Versionskontrollsystem installieren, habe damit aber noch gar keine Erfahrung.

[Warf]

Warum? Was sind die entscheidenden Unterschiede zwischen GIT und TortoiseSVN bzw. Vorteile von GIT?
Ich möchte mir jetzt, auch für meine anderen Projekte, ein lokales Versionskontrollsystem installieren, habe damit aber noch gar keine Erfahrung.

SVN ist zentralisiert, d.h. es gibt einen server auf dem alle daten liegen und mit jedem commit der server (und damit alle weiteren nutzer) geupdated werden. Git ist dezentral, das heißt jeder hat ein lokales, voll funktionsfähiges repository was man mit einem (oder mehreren) Server synchronisieren kann.

z.B. Du kannst das git mirror Repository von github forken, z.B. auf einem eigenen github repo oder auch bei einem anderen anbieten/eigener server, dann das repository lokal clonen, den mirror als separaten remote hinzufügen, lokal bei dir auf dem rechner arbeiten, gelegentlich mit deinem geforkten repository synchronisieren, und jederzeit vom mirror mit der neusten trunk version updaten (mergen).

Du kannst auch rein lokal arbeiten, den mirror clonen, auf einem neuen branch lokal arbeiten, änderungen commiten, etc. deine änderungen dann nie irgendwo hochladen, und jederzeit updates vom git mirror runterzuladen

[mschnell]

Vorteile von GIT?

Git arbeitet mit mehreren Repositories gleichzeitig, die lokal, auf Servern und lokal bei anderen Nutzern liegen können. Die lokalen Repositories der diversen Nutzer werden enstprechend verwaltet, Server können sich untereinander synchronisieren. Das ist ungeheuer leistungsfähig (ohne git wäre die Community-Entwicklung von Linux quasi nicht möglich), aber auch beliebig kompliziert es korrekt einzurichten.

Soweit ich weiß, ist git ursprünglich von Linus himself entwickelt worden.

-Michael

[Warf]

Soweit ich weiß, ist git ursprünglich von Linus himself entwickelt worden.

Und ist genauso gut durchdacht wie seine rants. Aber sagen wir es mal so, git hat die Versionskontrollsystemkriege gewonnen und ist jetzt der defacto Standard. Besser als SVN ist es alle mal, aber man sollte nicht vergessen das es auch noch andere VCS gibt die viele Sachen besser machen als git (z.B. mercurial). So kann es bei git vorkommen das man Commits verliert (Rebase verliert den link, nach ein paar tagen räumt der garbage collector lose commits auf) und dann sind deine Daten weg. Das ist genau das Gegenteil von dem Sinn und Zweck von Versionskontrollsystemen. Leider gehört rebase zum normalen git Workflow, es ist also so gesehen normal das man ein paar commits hier und da mal verloren gehen. Vor allem schön wenn durch das Rebase ein Bug zustande kommt in einem der späteren Commits, wenn man den zu spät bemerkt hat man keine chance so einfach wieder auf eine working version umzusteigen

[m.fuchs]

Aber sagen wir es mal so, git hat die Versionskontrollsystemkriege gewonnen und ist jetzt der defacto Standard. Besser als SVN ist es alle mal,

Steile Thesen.