VCS für dämliche Entwickler ;-)

[Assarbad]

Zitat von Sir Rufo:

Und eine SVN-Server (wie auch Git und die anderen) verarbeiten alles an Dateien ... am besten allerdings Text-Dateien ... somit also egal, was, wie und womit ich entwickle ... dem CVS ist das egal (auf Borland Star-Team kann man getrost verzichten)

SVN ist da zwar besser, aber immernoch nicht so toll. So sehr ich auch die "CVS keywords" (ursprünglich nur CVS aber in SVN verfügbar) an sich schätze, ein VCS hat gefälligst nie an meinen Daten rumzufummeln sondern die originalgetreu zu speichern und wieder rauszurücken. Weder SVN noch CVS halten sich da dran. Wenn ich schon das Rumgefummel mit den Zeilenumbrüchen sehe, kommt mir das Brechen ...

Bei SVN wird es auch sehr schnell sehr langsam. Wer einmal mehr als ein Release von Boost verwaltet hat und ohnehin schon ein großes Repo mit mehreren hundert Dateien und tausenden Revision hat, der wird die Geschwindigkeit von SVN nicht gerade schätzen. Einer der Gründe ist übrigens, daß in der Working Copy (daran wird wohl gearbeitet) immer diese .svn-Verzeichnisse mit Metadaten herumliegen. Und das nicht wie bei Git oder Mercurial nur auf der obersten Ebene sondern in jedem einzelnen Verzeichnis ...

Zitat von s.h.a.r.k:

Hab leider noch kein Git unter Linux installiert, also als "Server"-Software, sonst könnte ich da evtl. Hilfe anbieten. SVN war damals nicht so toll... Hatte es als Apache-Modul mal probiert, aber es gibt eben ein paar Hürden zu nehmen. Das will ich nicht nochmal machen Vielleicht gibts ja passende Pakete für das installierte Linux?!

Unter Debian und Ubuntu kinderleicht und selbst auf anderen Distros oder BSDs kein größeres Problem.

Das mit dem Apachemodul ist ein wenig ... nunja ... unglücklich. Denn wie auch Git oder Mercurial bietet SVN schon von Haus aus einen "serve"-Befehl, nämlich diesen. Nichts anderes passiert ja, wenn man einen SSH-Tunnel benutzt. Dort wird ja auch auf der entfernten Seite eine Instanz von svnserve gestartet um für den aktuellen Tunnel das Repo bereitzustellen. Ich denke also daß eine Erwähnung des Apachemoduls (mod_dav_svn, nehme ich mal an) nicht gerechtfertigt ist, da es beim Anbieten von Git und Mercurial über Apache ebenfalls Hürden gibt, die aber dann anderer Art sind (Proxy via mod_rewrite).

Bzgl. SVN via SSH-Tunnel kann man ja auch anderweitige Benutzung des Kontos direkt verbieten indem man das hier benutzt:

Code:

command="svnserve -t --tunnel-user=BenutzerName",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-dss AAA ...

[s.h.a.r.k]

Das mit diesen Unmengen an .svn-Ordnern kann ich auch irgendwie aus Design-Gründen nicht verstehen. Mag evtl. ganz nett sein, nur ein Pfad aus- und einchecken zu können, aber sonst sehe ich da keinen Sinn dahinter. Wobei das sehr auf Kosten des Nutzens und auch Geschwindigkeit geht. Allein schon das war ein Grund für mich auf Git umzusteigen. Da brauch ich mich auch nicht um irgendwelche versteckten Unterordner beim Upload auf meinen FTP scheren... Oder muss zuvor jedes mal noch exportieren.

[Lemmy]

Hi,

mal eine Frage an die Mercurial-Nutzer: Stimmt es wirklich dass Mercurial die Änderungen in unterschiedlichen Zweigen vernünftig mergen kann? Beispiel: Zweig 1 löscht einen Teil einer Methode bzw. die komplette Methode. Im Zweig 2 wird diese beibehalten. Beim Merge von 1 und 2 ist diese verflixte Methode dann auf einmal wieder da.

So wie ich die Tutorials von M. lese sollte es das können, habe es bei meinem kleinen Test aber nicht hinbekommen...

Grüße

[Assarbad]

Zitat von Lemmy:

mal eine Frage an die Mercurial-Nutzer: Stimmt es wirklich dass Mercurial die Änderungen in unterschiedlichen Zweigen vernünftig mergen kann? Beispiel: Zweig 1 löscht einen Teil einer Methode bzw. die komplette Methode. Im Zweig 2 wird diese beibehalten. Beim Merge von 1 und 2 ist diese verflixte Methode dann auf einmal wieder da.

Eigentlich schon. Aber Branches in Mercurial sind ohnehin etwas gewöhnungsbedürftig. Ich bevorzuge dafür einen lokalen Klon des Repos in dem ich wie in einer Branch weiterarbeitet und dann von upstream immer meine Änderungen pulle. Wenn ich dann bspw. ein Feature fertighabe, kann ich dann bequem alles pushen und das "entfernte" Repo hat auch die volle Versionshistorie.

Zitat von Lemmy:

So wie ich die Tutorials von M. lese sollte es das können, habe es bei meinem kleinen Test aber nicht hinbekommen...

Von welcher in welche Richtung? Kommandozeile oder TortoiseHg? Letzteres hat mir bei der Handhabung von Branches immer nur Kummer bereitet.

[s.h.a.r.k]

@Assarbad: Du schenist dich ja mit Mercurial auszukennen. Kennst du einen (guten) Artikel der die Unterschiede zwischen Git und Mercurial herausarbeitet?!

[Assarbad]

Zitat von s.h.a.r.k:

@Assarbad: Du schenist dich ja mit Mercurial auszukennen. Kennst du einen (guten) Artikel der die Unterschiede zwischen Git und Mercurial herausarbeitet?!

Keinen aktuellen, nein. Die älteren sind aber nicht mehr sinnvoll, weil sich beide eher annähern. Ein Beispiel wäre rebase, welches es in Mercurial vor einiger Zeit noch nicht gab.

[Lemmy]

@shark: Hier wird git kurz erwähnt.... http://hgbook.red-bean.com/read/how-...-get-here.html ALlerdings findet der Schreiber Mercurial toll

@Asserbad: Danke für den Hinweis. Ich habe die TortoiseHg verwendet, weil ich das unter SVN relativ gelungen finde.

[s.h.a.r.k]

Danke Lemmy! Ach, dass der Mercurial toll findet, überlebe ich dann wohl auch noch Ist halt -- wie so oft -- eine Glaubensfrage, was man denn lieber nutzt. So wie neulich der Thread mit diesen verschiedenen Merge-Tools. Aber schön, wenn man wenigstens eine Wahl hat

[Assarbad]

Zitat von s.h.a.r.k:

Danke Lemmy! Ach, dass der Mercurial toll findet, überlebe ich dann wohl auch noch Ist halt -- wie so oft -- eine Glaubensfrage, was man denn lieber nutzt.

Ich finde auch, daß es reine Geschmackssache ist. Wenn du Git derzeit benutzt und damit zufrieden bist, dann ist es doch nicht nötig zu wechseln. Git und Mercurial sind funktional sehr nah beieinander. Wenn du allerdings CVS benutzen würdest, könnte ich mich zu einer "Bekehrung" verleiten lassen

[s.h.a.r.k]

Ist aber immer interessant sich Alternativen anzuschauen und wie diese Arbeiten bzw. eben die Konzepte dahinter. Meinst du nicht mal, dass der Code von Git ein ziemliches "Gefrickel" sei?! Habe mir den noch nie angeschaut, ebenso von anderen OS-Systemen. Wobei ich dies bzgl eine Argumentation von Torvalds kenne, in der er eben gegen C++ mit OOP ist und für reines C stimmt -- soweit ich das noch weiß. Und Git wurde hier eben als Beispiel angeführt. Naja, das führt jetzt aber insgesamt wohl etwas in die falsche Richtung