Das deutsche Python-Forum

Guten Tag,

Ich habe noch nie mit einem Version Control System gearbeitet und möchte mir jetzt eins zulegen. Was würdet ihr mir empfehlen im Hinblick auf Bedienbarkeit und Integration in Emacs und andere Editoren?

Grüße
Panke

Panke hat geschrieben:Guten Tag,

Ich habe noch nie mit einem Version Control System gearbeitet und möchte mir jetzt eins zulegen. Was würdet ihr mir empfehlen im Hinblick auf Bedienbarkeit und Integration in Emacs und andere Editoren?

Grüße
Panke

Naja du musst zuerst mal eine Grundentscheidung treffen:
Verteilt oder Zentral.

Für ein Zentrales Repository empfehle ich dir Subversion.

Beim Dezentralen bin ich mir nicht so sicher
Ich bin derzeit Git und Bazaar am evaluieren. Falls jemand Erfahrungen mit einem dezentralen SCM hat würde mich das interessieren

Zentral vs. Dezentral scheint ein Heiliger Krieg zu sein Da ich bisher nur wenig Erfahrungen mit dezentralen SCM sammeln konnte halte ich mich aus dem jedoch heraus.

Noch was:
Verwende auf keinen, wirklich gar keinen Fall Micro$oft Sourcesafe. Begründen muss ich das vermutlich nicht. Im Zweifelsfall spuckt google genug Informationen heraus.

veers hat geschrieben: Beim Dezentralen bin ich mir nicht so sicher
Ich bin derzeit Git und Bazaar am evaluieren. Falls jemand Erfahrungen mit einem dezentralen SCM hat würde mich das interessieren

Ja. Bazaar ist furchtbar langsam und eingeschränkt, wird aber von Canonical ge"hypet". Git ist recht stabil und flott. Mercurial (hg) ist das auch, und darüberhinaus in Python geschrieben.

birkenfeld hat geschrieben:Ja. Bazaar ist furchtbar langsam und eingeschränkt, wird aber von Canonical ge"hypet".

Langsam, ja. Spielt für mich aber nicht so eine Rolle, das eh nur kleinere Projekte sind. Gehyped, Ja! Spätestens nach dem ich dauernd Werbung dafür gesehen habe (auf Freshmeat oder so), wurde mich das bewusst. Muss es aber nicht schlecht machen. Eingeschränkt, hm... Den Eindruck hatte ich weniger. Was fehlt dir den konkret?

Meine beiden Favoriten sind Subversion und Mercurial (hg). Subversion ist mittlerweile ein Standard im OpenSource-Bereich. Ist deswegen schon mal einen Blick wert.

veers hat geschrieben:

birkenfeld hat geschrieben:Ja. Bazaar ist furchtbar langsam und eingeschränkt, wird aber von Canonical ge"hypet".

Langsam, ja. Spielt für mich aber nicht so eine Rolle, das eh nur kleinere Projekte sind. Gehyped, Ja! Spätestens nach dem ich dauernd Werbung dafür gesehen habe (auf Freshmeat oder so), wurde mich das bewusst. Muss es aber nicht schlecht machen. Eingeschränkt, hm... Den Eindruck hatte ich weniger. Was fehlt dir den konkret?

er mag es einfach nur nicht, dass ist alles
und so langsam ist es auch nicht(zumindest bei mir), ist ungefähr genauso schnell wie subversion(je nach operation)
des weiteren ist bzr auch in python geschrieben, ohne hässliche C-Zusätze

welterde hat geschrieben:er mag es einfach nur nicht, dass ist alles
und so langsam ist es auch nicht(zumindest bei mir), ist ungefähr genauso schnell wie subversion(je nach operation)
des weiteren ist bzr auch in python geschrieben, ohne hässliche C-Zusätze

SVN ist in vielen Fällen aber (vergleichsweise) langsam

Und ob ich das toll finden soll das es in reinem Python geschrieben ist weis ich nicht. Die Performance wird es auf jeden Fall nicht erhöhen

Da du ein überzeugter bzr Nutzer zu sein scheinst, warum sollte ich bzr benutzen? Was macht bzr toller als git, hg oder (urgs) tla/arch.

welterde hat geschrieben:so langsam ist es auch nicht(zumindest bei mir), ist ungefähr genauso schnell wie subversion(je nach operation)

Auf Projekten welcher Groesse denn? Wenn ich mich recht entsinne, hat Mozilla vor dem Umstieg auf Mercurial einige Benchmarks durchgefuehrt, bei denen bazaar gnadenlos abgekackt ist.

lumax hat geschrieben:Auf Projekten welcher Groesse denn? Wenn ich mich recht entsinne, hat Mozilla vor dem Umstieg auf Mercurial einige Benchmarks durchgefuehrt, bei denen bazaar gnadenlos abgekackt ist.

Gut, das war vermutlich schon eine Weile her. Wird in vielen Fällen auch nicht relevant sein weil nur Wenige Projekte so gross sind wie Mozilla

veers hat geschrieben: Noch was:
Verwende auf keinen, wirklich gar keinen Fall Micro$oft Sourcesafe. Begründen muss ich das vermutlich nicht. Im Zweifelsfall spuckt google genug Informationen heraus.

Den meisten würde schon reichen das es von MS ist

Und höchstwarscheinlich nicht unter Linux lauffähig

Subversion ist natürlich ein Klassiker, bei dem man nicht besonders viel falsch machen kann. Gesetzt den Fall natürlich, dass man einen externen Host für das Repo verwenden kann. Das gibt SVN den Vorteil, als Basis für Trac und als "externes Backup" für den Quellcode dienen zu können. Durch seine Bestimmung als "zentralisiertes System" ist es dafür halt prädestiniert (na, wer erkennt den Pleonasmus?). Dann kann man allerdings weder lokale und private Branches verwirklichen noch offline Quellcode comitten. Zu dem Zweck ist allerdings SVK toll - kompatibel zu Subversion, aber mit lokalen (und entfernten) Repos.

Dagegen stehen wohl bei den meisten Anhängern von Python Mercurial und Bazaar. Bazaar wurde ja schon genannt - wichtig dazuzusagen ist, dass Bazaar auch Subversion-Branches verwenden kann. Interessant wird das beim Einsatz von Trac (oder halt ganz Subversion) im Projekt. Dafür kann man bei reinen Bazaar-Entwicklungsteams trac nicht ohne weiteres verwenden. trac-bzr hat bei mir nicht geklappt.

Mercurial als Gegenstück dazu bietet die Möglichkeit nicht, Subversion zu integrieren. Mit Klimmzügen geht es über tailor aber für die tägliche Arbeit ist das etwas sehr wirr. Wenn man allerdings die Möglichkeit hat, "nur" Mercurial einzusetzen, klappt das wunderbar. Tolles Versionssystem, dazu wurde ja schon viel gesagt. Davon abgesehen gibt es Trac-HG, was wunderbar funktioniert.

Für "heimcoderei" unterscheiden sich die meisten Systeme zur Versionskontrolle nicht wirklich wesentlich. Trac allerdings kann ziemlich viel rausreißen.

lumax hat geschrieben:

welterde hat geschrieben:so langsam ist es auch nicht(zumindest bei mir), ist ungefähr genauso schnell wie subversion(je nach operation)

Auf Projekten welcher Groesse denn? Wenn ich mich recht entsinne, hat Mozilla vor dem Umstieg auf Mercurial einige Benchmarks durchgefuehrt, bei denen bazaar gnadenlos abgekackt ist.

Ich kenn einen viel besseren Benchmark, er heißt ausprobiern
Projektgröße? naja, so klein bis mittel
@veers außerdem halte ich es für leichter bedienbar als andere VCS
des weiteren gibts auch mehr plugins für bzr, als für die meisten(?) anderen

welterde hat geschrieben:

veers hat geschrieben:

birkenfeld hat geschrieben:Ja. Bazaar ist furchtbar langsam und eingeschränkt, wird aber von Canonical ge"hypet".

Langsam, ja. Spielt für mich aber nicht so eine Rolle, das eh nur kleinere Projekte sind. Gehyped, Ja! Spätestens nach dem ich dauernd Werbung dafür gesehen habe (auf Freshmeat oder so), wurde mich das bewusst. Muss es aber nicht schlecht machen. Eingeschränkt, hm... Den Eindruck hatte ich weniger. Was fehlt dir den konkret?

er mag es einfach nur nicht, dass ist alles

Ja, ich stehe damit auch ganz allein da.

und so langsam ist es auch nicht(zumindest bei mir), ist ungefähr genauso schnell wie subversion(je nach operation)
des weiteren ist bzr auch in python geschrieben, ohne hässliche C-Zusätze

Wenn du C nicht magst, solltest du Python allerdings nicht mehr einsetzen.

birkenfeld hat geschrieben:Ja, ich stehe damit auch ganz allein da.

*böses unterstell* es gibt ja auch leute, die finden M$ gut
oder linux schlecht *noch böseres unterstell*
aber davon fangen wir besser nicht an


und in welcher weise ist bazaar beschränkt?

birkenfeld hat geschrieben:Wenn du C nicht magst, solltest du Python allerdings nicht mehr einsetzen.

ach, jetzt auch noch python schlecht machen.... *schlimm, schlimm*

aber anstatt, die jeweils anderen VCS durch den Kakao zu ziehen, sollten wir besser die coolen features, der jeweiligen vcs hervorheben, nich?

Features von bzr: laaaaaaaaannnnnnngggggsam. dafür nette API. aber laaaaaaannngsam.

Mein Tipp (mirakle wipp^W^W) Mercurial, oder Subversion wenn man closed source zeug macht, für open source Projekte find ichs mittlerweile einfach nur eine schlechte Idee, da hat Linus' Präsentation geholfen. Ansonsten ist git einen Blick wert, da tut sich momentan viel.

welterde hat geschrieben:

birkenfeld hat geschrieben:Ja, ich stehe damit auch ganz allein da.

*böses unterstell* es gibt ja auch leute, die finden M$ gut
oder linux schlecht *noch böseres unterstell*
aber davon fangen wir besser nicht an

Da fehlt mir jetzt der Zusammenhang.

birkenfeld hat geschrieben:Wenn du C nicht magst, solltest du Python allerdings nicht mehr einsetzen.

ach, jetzt auch noch python schlecht machen.... *schlimm, schlimm*

Non sequitur.

aber anstatt, die jeweils anderen VCS durch den Kakao zu ziehen, sollten wir besser die coolen features, der jeweiligen vcs hervorheben, nich?

Dann fang besser mal an.

blackbird hat geschrieben:für open source Projekte find ichs mittlerweile einfach nur eine schlechte Idee, da hat Linus' Präsentation geholfen.

Hallo blackbird!

Du sprichst in Rätseln. Welche Präsentation? So viele Projekte mit mehr als 10 gleichzeitigen Mitarbeitern gibt es jetzt auch wieder nicht. Warum gegen Subversion??? Ich arbeite im Durchschnitt mit 2-4 Personen an Projekten, die in SVN-Repositories liegen. Dabei bin ich aber immer die letzte Instanz. Ich bin für den Code verantwortlich und gebe die Regeln vor. Ich denke mal, dass bei den meisten Projekten eine oder zwei Personen die oberste Instanz dar stellen, die die Regeln vorgeben und anderen Entwicklern ihren eigenen Branch für Teilprojekte zuweisen und letztendlich auch das OK für die Einbindung eines Branches in den Trunk geben.

SVN ist unter Windows sehr gut in den Explorer integriert und mit pySVN-Workbench http://pysvn.tigris.org/docs/WorkBench.html gibt es auch einen GUI-Client, der angeblich nicht schlecht sein soll. Mit den Hooks, können serverseitig z.B. beim "Commiten" des Quellcodes Programme ausgeführt werden. Ich nutze das z.B. um Websites und Intranetsites von Kunden lokal zu entwickeln. Der neueste Tag stellt die Website dar, die automatisch aktualisiert wird. Das funktioniert sogar mit Zope, wenn man im Dateisystem entwickelt.

lg
Gerold

gerold hat geschrieben:Du sprichst in Rätseln. Welche Präsentation? So viele Projekte mit mehr als 10 gleichzeitigen Mitarbeitern gibt es jetzt auch wieder nicht. Warum gegen Subversion??? Ich arbeite im Durchschnitt mit 2-4 Personen an Projekten, die in SVN-Repositories liegen. Dabei bin ich aber immer die letzte Instanz. Ich bin für den Code verantwortlich und gebe die Regeln vor. Ich denke mal, dass bei den meisten Projekten eine oder zwei Personen die oberste Instanz dar stellen, die die Regeln vorgeben und anderen Entwicklern ihren eigenen Branch für Teilprojekte zuweisen und letztendlich auch das OK für die Einbindung eines Branches in den Trunk geben.

http://www.youtube.com/watch?v=4XpnKHJAok8

Anschauen, das erklärt auch die Frage

http://www.opensolaris.org/os/community ... /bzr-eval/

Local clone of this repository: 23m02s - 25m31s over three runs.
Local commit of one file in the repository: 16m47s.

Das ist nicht langsam, das ist unbrauchbar!

http://www.opensolaris.org/os/community ... -final.txt

Local clone of the same repository: 2m35s
Local commit of one file in the repository: 9s

Wobei zumindest als das getestet wurde Git kein (funktionierendes/history erhaltendes) mv hatte.

Werde mir Mercurial wohl doch noch ansehen.

blackbird hat geschrieben:http://www.youtube.com/watch?v=4XpnKHJAok8

Da sieht man wieder, wie man sich von Idolen beeinflussen lassen kann.

Es gibt Anwendungsgebiete in denen SVN besser ist und es gibt Anwendungsgebiete in denen GIT besser ist. Einfach ein System pauschal zu verteufeln halte ich nicht für sinnvoll.

lg
Gerold