proggen.org

Ich benutze für meine Projekte auch Git, bin auch sehr zufrieden damit.
Benutzen tue ich es lokal auf meinem Rechner (Linux), hatte für diese Zwecke auch schon Bazaar ausprobiert, wobei ich von der Bedienung keinen sooo großen Unterschied feststellen konnte... (ich verwalte mein Repository nur über die Konsole).

Dirty Oerti hat geschrieben: Bazaar oder Mercurial würden mich auch interessieren, damit kenne ich mich aber nicht aus.

Meiner Meinung nach unterscheiden sich alle dezentralen Systeme (Git, Bazaar, Mercurial) nur sehr wenig. Ist eher eine Frage des Geschmacks...

Zu SVN: Es ist nicht mein Fall, finde die Bedienung oft etwas umständlich, bin mit Git schneller zum Ziel gekommen.

hofian hat geschrieben:Zu SVN: Es ist nicht mein Fall, finde die Bedienung oft etwas umständlich,[...]

Ich hab mit SVN eigentlich auch immer wieder Probleme gehabt. Aber es gibt ja Gott sei dank auch bzr-svn, da kann man auch super mit einem SVN-Server arbeiten. Manchmal sogar besser als mit dem eigentlichen SVN-Client

Kerli hat geschrieben:

hofian hat geschrieben:Zu SVN: Es ist nicht mein Fall, finde die Bedienung oft etwas umständlich,[...]

Ich hab mit SVN eigentlich auch immer wieder Probleme gehabt. Aber es gibt ja Gott sei dank auch bzr-svn, da kann man auch super mit einem SVN-Server arbeiten. Manchmal sogar besser als mit dem eigentlichen SVN-Client

Probleme welcher Art? Ich kann nicht daran erinnern mit SVN jemals Probleme gehabt zu haben.

Also mit diesem Tut hier, habe ich angefangen mir Git beizubringen. (Etwas runterscrollen, ganz oben steht noch SVN)

git-Server per SSH einrichten:

http://www.squatlabs.de/versionierung/g ... sam-nutzen

Das deckt zumindest den Part ab.
Ich weiß nicht mehr wie, aber irgendwie kann man es auch über HTTP schleusen.
Die Option PATCH-MAILS bleibt einem immer offen.

Arbeiten mit git ist eigentlich ähnlich zu SVN (und wohl auch zu allen anderen Versionsverwaltungssystemen ^^)

git add DATEI fügt eine neue Datei zum Repo hinzu oder nimmt eine geänderte ins Repo auf
git commit Erstellt einen neuen Commit. Es wird der Standardeditor gestartet, um die Commitmessage zu verfassen (ohne geht nicht)
git commit -a Wenn man nicht alle geänderten Dateien per git add hinzufügen möchte.
git push origin BRANCH um das ganze auf den eingestellten Origin (Ursprung) hochzuladen
git pull um das lokale Repo auf den neusten Stand zu bringen

Wenn es Konflikte gibt, dann werden die nett mitgeteilt und man muss die Dateien eben (mit dem Editor den man bevorzugt^^) zusammenbringen.
Dann ein Commit und man hat ein "merge"

Ansonsten wichtig:

git diff zeigt die lokalen Unterschiede zur letzten Version an.
git status den Status ...

git branch NAME erzeugt einen branch NAME
git checkout BRANCH wechselt zum angegebenen Branch.

Wenn ich sonst nicht weiß, wie was geht, dann geh ich meistens hier hin, da steht eigentlich alles
http://www.kernel.org/pub/software/scm/ ... s/git.html
(Commandliste kommt recht weit unten)

SVN hat halt in meinen Augen den Nachteil, dass ich keine lokalen Commits anfertigen kann und (soweit ich weiß) auch nicht mit lokalen Branches arbeiten kann.
Sprich um richtig arbeiten zu müssen muss ich online sein.

Ich werde mir am Wochenende mal Dirty Oerti schnappen und mit ihm ein Git-Repository testweise installieren und mit ihm die Unterschiede zu SVN erörtern.
Das ist ein Lernprojekt und den Anspruch soll es auch an dieser Stelle behalten.

Andererseits ist das Ziel eines jeden Projektes jedoch auch, sich zu entwickeln. Das bedeutet, dass die Versionsverwaltung nur ein Werkzeug ist, es nimmt nämlich auf die Qualität des Quellcodes keinen Einfluss.
Heißt: wenn ich am Wochenende erkenne, dass Git im Vergleich zu Svn Nachteile in der Verwendung oder Wartung hat, dann wird Subversion verwendet.

Lernprojekt heißt auch, dass Leute, die keinerlei Erfahrung mit Versionsverwaltungen haben, nicht noch zusätzlich zwischen lokalen und serverseitigen Commits unterscheiden können müssen, wenn sie erstmal lernen müssen, was ein Commit überhaupt ist.

Ok
Da schaun wir dann einfach mal, ob und wenn ja wie einfach und praktikabel es ist einen Gitserver einzurichten. Sollte das nicht klappen dann ist ja schonmal klar, dass die Versionsverwaltung auf SVN fällt (SVN-Repos hatten wir ja schonmal unter proggen.org laufen)

Git hat halt den Vorteil, dass wir uns absolut nicht um Backups kümmern müssen, sollte der Server mal Adieu sagen.
So vom "Workflow" her kommt es eigentlich eh aufs gleiche wie bei SVN raus

@Xin: Wann/wie/wo hast du Zeit?

Dirty Oerti hat geschrieben:@Xin: Wann/wie/wo hast du Zeit?

Ich habe mir wieder einen Programmierschüler aufgehalst, dem ich versprach ihn am Donnerstag mit C-Grundlagen zu verschrecken.

Wir haben da so einen Deal: Ich nerve ihn mit C, er nervt mich damit, dass ich beim Joggen nicht mit ihm mithalten kann...
Damit er Frust abbauen kann, gehen wir danach dann joggen.

Wenn ich dann frustriert die Treppe hochkomme und nicht unter der Dusche zusammenbreche, hätte ich prinzipiell Donnerstags abends Zeit dafür. Dann können wir uns gleich mal Skype usw. klar machen, da wir uns ja auch noch ums Design kümmern wollten... was mich daran erinnert, dass ich mein Headset mitnehmen sollte. ^^

Ok, dann halten wir mal Donnerstab Abend fest
Ich werd dann einfach (wahrscheinlich schon ab Nachmittag) Skype anmachen, sobald du Zeit hast schreibst/rufst du mich halt an (Skypename war danieloertwig)

Dirty Oerti und ich haben heute begonnen ein Git-Repository nach den vorgestellten Tutorials aufzusetzen.
Allerdings lies sich die Autorisierung nicht wie gewünscht handhaben und das Setup von gitosis konnte nicht erfolgreich durchgeführt werden. Die Anmeldung und 'Tunnelung' über einen git-User behagt mir ebenfalls nicht. Die erforderliche Schlüsselverwaltung, die Zugriff auf den User Git erlaubt, ist nicht akzeptabel und keinem Einsteiger sinnvoll zu vermitteln, insbesondere dann nicht, wenn mit Subversion eine bewährte Alternative zur Verfügung steht, die für die vorhandenen Probleme Lösungen mitbringt.

Womit wir wieder bei Subversion wären. Wir haben eine neue Domain: svn.proggen.org, und unter svn.proggen.org/dedupe findet sich nun das Subversionrepository, was über das [url=svn://svn.proggen.org/dedupe]SVN[/url] und HTTP-Protokoll erreichbar ist.
Schreibrechte gibt's jedoch erst nach Anmeldung. Ich werde mir morgen das CMake-Projekt ansehen und es dann auch einchecken.