juhu, die canonical pr maschinerie mal wieder... aber trotzdem gibt mir bzr nichts was nicht auch git und mercurial zu bieten hätten, ausser vielleicht viele nervige wechsel beim repository format. und wenns um contributions von der community geht, kommt mir hierbei einfach nur die galle hoch. ok, bei anderen (z.B. intel) muss man auch das copyright abtreten...
Von Julian Andres Klode am Mi, 7. Oktober 2009 um 13:27 #
Solche Vereinbarungen sind aber eigentlich was ganz normales, und werden z.B. auch von der FSF gemacht. Außerdem wird Canonical bestimmt auch nicht nein sagen, wenn Code benötigt wird und der eben von mehreren Leuten ohne Vereinbarung ist. Wobei ich mich frage, ob diese Vereinbarung in Deutschland überhaupt gültig sind, denn soweit ich weiß kann man kein Urheberrecht abtreten, sondern nur sehr breite Rechte weitergeben.
Von Julian Andres Klode am Mi, 7. Oktober 2009 um 13:35 #
Wobei man auch einfach eine Lizenz wie die Apache License 2.0 wählen könnte, welche das in Paragraphen 2 und 5 ziemlich genau klärt. Der einzige Grund da solche Vereinbarungen zu haben, ist die Möglichkeit später die Lizenz zu wechseln ohne den alten Apache Header behalten zu müssen. Außerdem hat man auf diese Weise einfach kürzere Datei-Header, da es nur einen Rechteinhaber gibt anstatt mehrere.
Außerdem wird Canonical bestimmt auch nicht nein sagen, wenn Code benötigt wird und der eben von mehreren Leuten ohne Vereinbarung ist.
ich denke nicht, denn canonical bietet bzr auch unter einer proprietären lizenz an: "To embed Bazaar into products under a different license, please contact Canonical with your needs"
Man kann sein Urheberrecht nicht abtreten, das bleibt immer fest verbunden mit dem Werk und seinem Autor. Das amerikanische Copyright ist aber nicht das deutsche Urheberrecht, sondern ein Reproduktionsrecht!
Von Julian Andres Klode am Do, 8. Oktober 2009 um 13:15 #
Vielleicht nicht für bzr, aber für Programme die selbst GPL libraries benutzen (update-manager,software-store) kann ich mir das schon vorstellen, denn sie können die ja sowieso nicht under einer proprietären Lizenz weitergeben.
"aber trotzdem gibt mir bzr nichts was nicht auch git und mercurial zu bieten hätten, ausser vielleicht viele nervige wechsel beim repository format."
Dein Satz legt nahe das Bazaar keine Existenzberechtigung hat weil es git und mercirual gibt, aber faktisch sind sie in etwa alle gleich alt. Daher könnte man das genauso gut anders herum fragen. Allgemein gibt es git weil z.B. mercurial damals einfach zu langsam war (noch schlecht optimierter Python Code). Shit happens.
Außerdem irrst du dich. Bazaar lief schon gut unter Windows, als git es nicht tat (tut git es eigentlich heute, habe es lange nicht mehr probiert?). Daher viel bei einigen Projekten git bei der Auswahl eines neuen VCS auch durch.
Naaajjjaaa, so hart würde ich es auch wieder nicht sagen. Mercurial war damals wohl wirklich lahm (wenn mich meine Erinnerung nicht täuscht), und das war ihm wohl halt wichtig. Wenn ich mich zudem richtig erinnere (ich finde die Diskussion/Beiträge von damals grad nicht) war speziell mercurial damals aber als funktionell gut bezeichnet worden, auch von ihm. Hat einer gerade links zur hand?
Wäre gut möglich, ich kann mir zudem allerdings aktuell das Video nicht anschauen.
"AFAIK wurden sowohl mercurial als auch git mehr oder weniger zur gleichen Zeit entwickelt"
Mehr oder weniger ja, habe ich ja auch geschrieben (2x). Allerdings war mercurial IHMO dennoch knapp vorher da, und wenn ich mich nicht täusche durchaus Teil der Diskussion. Jedoch könntest du auch wie gesagt recht haben und die von mir vermuteten vergleiche (geschwindigkeit und co.) bezogen sich eher auf monotone.
natürlich hat bzr genau wie git und hg seine daseinsberechtigung. die projekte treiben sich ja auch in sachen funktionsumfang voreinander her, wovon ja schliesslich alle profitieren. ich nutze bzr auch, das hängt nur vom jeweiligen projekt ab. die meisten sachen mit denen ich zu tun habe (gnome, fd.o) sind allerdings auf git umgestiegen, welches mir durch tägliche anwendung dann natürlich auch am meisten ans herz gewachsen ist. und einige features von git gingen mir bei bzr bisher einfach ab: inline branches, bisect und (interactive) rebase. falls sich das mittlerweile geändert hat lasse ich mich gerne eines besseren belehren
Git, Bazaar und Mercurial sind sich sehr ähnlich, haben aber trotzdem unterschiede. Ich arbeite zum Beispiel lieber mit Bazaar als mit Git, da mir das User Interface dort besser gefällt. Die Befehle sind meiner Ansicht nach konsistenter benannt und besser zu handhaben. Git wirkt an dieser Stelle manchmal etwas chaotisch. Außerdem sagt mit die einfachere Erweiterung über Python-Plugins bei Bazaar sehr zu. Bei *sehr* umfangreichen Source-Code profitiert man bei Git aber nach wie vor von der besseren Performance. Grundsätzlich könnte ich mir auch vorstellen, mit Mercurial zu arbeiten. Habe ich bislang aber nur angetestet und bislang keinen Grund gehabt zu wechseln.
Ansonsten können alle Systeme dank Fast Import/Export auch gut miteinander (und das ist in erster Linie ein Verdienst des Git-Projekts).
Meines wissens hat bzr schon ein Alleinstellungsmerkmal: Wenn man in Branch A eine Datei umbenennt und in Branch B diese bearbeitet ist dass für den merge kein Problem. Alle anderen Systeme arbeiten mit copy und delete. Meines wissen hat nur bzr ein echtes move.
Bei hg ist das renaming meiner Meinung nach auch nicht gut implementiert. Beispiel: Revision1: DateiA Revision2: DateiA wird in DateiB umbenannt. hg cat -r1 DateiB findet kein Ergebnis :-/ Auch bei hg log muss man erst --follow angeben. Das ist für meine Programmierpraxis ungeeignet.
Damit will ich nicht hg oder git schlecht reden, die haben sicher auch Vorteile (bisect ist bei bzr nur per Plugin vorhanden) ein copy mit History gibt es bei Bzr gar nicht. Also von daher haben die Tools schon Ihre Berechtigung.
> Wenn man in Branch A eine Datei umbenennt und in Branch B diese bearbeitet ist dass für den merge kein Problem.
git arbeitet nicht auf Dateibasis. Es ist git völlig egal, wieviele Dateien du in welchen Branches umbenennst und veränderst. Intern werden immer die gleichen Objekte verwendet. Das ist der Grund warum es unter Anderem so toll mergen kann.
Ja, trotzdem hat der Vorposter im Kern Recht. Git kennt kein echtes verschieben, auch wenn es recht geschickt versucht, das Verschieben einer Datei im Nachhinein beim Mergen zu erkennen.
(Habe mal eine Überschrift gewählt die Mark Shuttleworth versteht.)
Ich bin für Choice etc, aber wenn es doch ein weiter verbreitetes und überlegeneres SCM gibt (git), warum schreibt man dann nicht seine Kosten ab (sunk costs) und wechselt .. dass bald alles in Ubuntu in bzr stecken soll ist doch wohl einfach nur albern.
Git ist nicht wirklich kompliziert, es ist einfach nur anders. Und es ist wohl kein Wunder warum sich um git coole Sachen wie github und gitorious entwickelt haben und um bzr nicht (oder warum Python hg gewählt hat und nicht bzr .. ebenso Gnome, KDE, X, Kernel etc).
Aber es gab bazaar schon als git angefangen. Daher leidete eher Linus darunter.
Wie oben schon geschrieben ist git nuneinmal nicht vorher da gewesen, und die gründe für git, und gegen die anderen sind teils sehr subjektiv, und manche einfach eine Geschmacksfrage.
>> Ich bin für Choice etc, aber wenn es doch ein weiter verbreitetes und überlegeneres SCM gibt (git), warum schreibt man dann nicht seine Kosten ab (sunk costs) und wechselt .. dass bald alles in Ubuntu in bzr stecken soll ist doch wohl einfach nur albern.
Tja, da muss man sich die Frage stellen, ob man git hätte ab die Canonical Bedürfnisse anpassen können, ohne dabei groß mit Upstream zu brechen. Wenn man in Betracht zieht, wer git entwickelt hat und unter wessen Schirmherrschaft es steht, dann möchte ich das doch stark bezweifeln.
>> Und es ist wohl kein Wunder warum sich um git coole Sachen wie github und gitorious entwickelt haben und um bzr nicht http://launchpad.net
>> oder warum Python hg gewählt hat und nicht bzr .. ebenso Gnome, KDE, X, Kernel etc Guido van Rossum (Python): "It's hard to explain my reasons for choosing -- like most language decisions (especially the difficult ones) it's mostly a matter of gut feelings." Ja, da scheint es echt riesige Bedenken gegen bzr gegeben zu haben...
Ja, wenn bzr heute entwickelt werden würde, könnte man sich das fragen. Das liegt jetzt aber auch schon 2 Jahre zurück und niemand konnte damals in die Zukunft blicken.
Einfach mal freuen, dass wir mind. 3 gute Versionsverwaltungssystem haben. Also in dem Bereich braucht man sich echt keine Sorgen zu machen.
...kann ich sagen, dass ich ganz zufrieden damit bin. Sowohl für kleinere als auch größere Projekte verwende ich seit zwei Jahren bzr. Die Performance genügte meinen Ansprüchen schon immer aber seit der Zeit hat sie sich auch noch deutlich spürbar verbessert. Das Kommandozeilen-Interface halte ich für sehr gut durchdacht. Der Quellcode ist von hervorragender Qualität und leicht verständlich. Vielleicht kann man das gleiche über hg sagen aber bisher sah ich keinen Grund zu wechseln. Für hg spricht die Unterstützung durch Google Code und Bitbucket (So ein richtiger Fan von Launchpad bin ich nie geworden - obwohl das auch tolle Features hat). Aus heutiger Sicht scheint git mehr für Leute zu sein, die Vorurteile gegenüber interpretierten Sprachen haben (also selbst eher zu den reinen C/C++ Entwicklern gehören) oder am Kernel rumbasteln wollen
Von Julian Andres Klode am Do, 8. Oktober 2009 um 01:14 #
Der Unterschied in Speicherverbrauch und Geschwindigkeit immer noch gewaltig. So benötigt git für eine Aktion 1ms für die bzr 100ms benötigt. Ein weiteres Problem mit bzr sind die Revisionsnummern, einmal bzr pull/push gemacht und schon hast du andere Nummern (im jeweiligen Repository).
Ansonsten finde ich git einfach angenehmer zum Arbeiten. Dinge wie das automatische Paging, die wunderbar kolorierten diffs, einfaches History rewriting (lokale branches rebasen, etc.) machen das Leben viel einfacher. Und die Kombination git-buildpackage + pristine-tar macht die Wartung von Debian Paketen extrem einfach. Hooks sind viel einfacher, und werden in .git/hooks im Repository gespeichert, anstatt außerhalb wie bei bzr. Sicherlich bietet auch bzr einige Vorteile, wie z.B. einen enormen Umfang an Meta-Informationen in commits wenn man welche reinschreibt und mehr.
Launchpad kann ja auch git repositories importieren und dann bzr repositories zur Verfügung stellen, was auch ganz nett ist. Außerdem müsste man auch mit bzr-git in der Lage sein, einen r/w Mirror zu erstellen, ausprobiert hab ich sowas aber noch nicht.
Anyway, beide funktionieren gut, beide haben ihre Vor- und Nachteile. Aber letztendlich muss sowieso jeder/jede der/die am Kernel oder GNOME hacked und gleichzeitig noch an Ubuntu mitarbeitet beides können. Und will er/sie noch an Python hacken, so muss er/sie auch noch Mercurial beherrschen
Hmm... Mir scheint momentan eher der Trend in Richtung Git zu gehen. Nicht nur das viele bekannte Projekte auf Git gewechselt sind auch liest man in bekannten englischsprachigen Programmier Q&A Seiten vermehrt über Git. Tortoise hat selber ein Git Tool was ähnlich TortoiseSVN arbeitet rausgebracht und es gibt selbst ein Plugin für Visual Studio (Git Extension) und auch unter Linux und Mac gibt es recht vernüftige grafische Tools und selbst ein Plugin für Eclipse ist schon zu bekommen.
Es gibt im Grunde so 2 Sachen die unbedingt in Git rein müssten, damit es noch eine grössere Akzeptanz findet. Zum einen partielles auschecken und zum zweiten das auch leere Verzeichnisse akzeptiert werden. Das mit den Submodulen ist zwar mehr oder weniger als Workaround benutzbar aber gerade das ist ein Punkt der bei Subversion ja sehr gut und einfach funktioniert.
Bazaar wird von Canonical etwas gepusht und es ist auch gut mehrere Systeme zur Auswahl zu haben. Aber IMHO hat Git die momentan besseren Ansätze und das nicht nur im Bereich Performance. Wenn die GUI Tools noch besser werden und auch mehr Features von Git da unterstützt werden und zudem noch paar der oft gewünschten Features zukommen, ist Git eine richtig runde Sache.
und wenns um contributions von der community geht, kommt mir hierbei einfach nur die galle hoch. ok, bei anderen (z.B. intel) muss man auch das copyright abtreten...
Wobei ich mich frage, ob diese Vereinbarung in Deutschland überhaupt gültig sind, denn soweit ich weiß kann man kein Urheberrecht abtreten, sondern nur sehr breite Rechte weitergeben.
ich denke nicht, denn canonical bietet bzr auch unter einer proprietären lizenz an: "To embed Bazaar into products under a different license, please contact Canonical with your needs"
Dein Satz legt nahe das Bazaar keine Existenzberechtigung hat weil es git und mercirual gibt, aber faktisch sind sie in etwa alle gleich alt. Daher könnte man das genauso gut anders herum fragen.
Allgemein gibt es git weil z.B. mercurial damals einfach zu langsam war (noch schlecht optimierter Python Code). Shit happens.
Außerdem irrst du dich. Bazaar lief schon gut unter Windows, als git es nicht tat (tut git es eigentlich heute, habe es lange nicht mehr probiert?). Daher viel bei einigen Projekten git bei der Auswahl eines neuen VCS auch durch.
Naja, allgemein gibt es git, weil Linus Tovalds ein Ego hat, dass ihm vorschreibt, alles andere als grundsätzlich minderwertig zu betrachten
Hat einer gerade links zur hand?
AFAIK wurden sowohl mercurial als auch git mehr oder weniger zur gleichen Zeit entwickelt: Google TechTalks 2006
Wäre gut möglich, ich kann mir zudem allerdings aktuell das Video nicht anschauen.
"AFAIK wurden sowohl mercurial als auch git mehr oder weniger zur gleichen Zeit entwickelt"
Mehr oder weniger ja, habe ich ja auch geschrieben (2x). Allerdings war mercurial IHMO dennoch knapp vorher da, und wenn ich mich nicht täusche durchaus Teil der Diskussion. Jedoch könntest du auch wie gesagt recht haben und die von mir vermuteten vergleiche (geschwindigkeit und co.) bezogen sich eher auf monotone.
ich nutze bzr auch, das hängt nur vom jeweiligen projekt ab. die meisten sachen mit denen ich zu tun habe (gnome, fd.o) sind allerdings auf git umgestiegen, welches mir durch tägliche anwendung dann natürlich auch am meisten ans herz gewachsen ist. und einige features von git gingen mir bei bzr bisher einfach ab: inline branches, bisect und (interactive) rebase. falls sich das mittlerweile geändert hat lasse ich mich gerne eines besseren belehren
Ansonsten können alle Systeme dank Fast Import/Export auch gut miteinander (und das ist in erster Linie ein Verdienst des Git-Projekts).
Wenn man in Branch A eine Datei umbenennt und in Branch B diese bearbeitet ist dass für den merge kein Problem. Alle anderen Systeme arbeiten mit copy und delete. Meines wissen hat nur bzr ein echtes move.
Bei hg ist das renaming meiner Meinung nach auch nicht gut implementiert. Beispiel:
Revision1: DateiA
Revision2: DateiA wird in DateiB umbenannt.
hg cat -r1 DateiB findet kein Ergebnis :-/ Auch bei hg log muss man erst --follow angeben. Das ist für meine Programmierpraxis ungeeignet.
Damit will ich nicht hg oder git schlecht reden, die haben sicher auch Vorteile (bisect ist bei bzr nur per Plugin vorhanden) ein copy mit History gibt es bei Bzr gar nicht.
Also von daher haben die Tools schon Ihre Berechtigung.
git arbeitet nicht auf Dateibasis. Es ist git völlig egal, wieviele Dateien du in welchen Branches umbenennst und veränderst. Intern werden immer die gleichen Objekte verwendet. Das ist der Grund warum es unter Anderem so toll mergen kann.
Ich bin für Choice etc, aber wenn es doch ein weiter verbreitetes und überlegeneres SCM gibt (git), warum schreibt man dann nicht seine Kosten ab (sunk costs) und wechselt .. dass bald alles in Ubuntu in bzr stecken soll ist doch wohl einfach nur albern.
Git ist nicht wirklich kompliziert, es ist einfach nur anders. Und es ist wohl kein Wunder warum sich um git coole Sachen wie github und gitorious entwickelt haben und um bzr nicht (oder warum Python hg gewählt hat und nicht bzr .. ebenso Gnome, KDE, X, Kernel etc).
Canonical (Mark) leidet auch ein wenig an NIH.
Aber es gab bazaar schon als git angefangen. Daher leidete eher Linus darunter.
Wie oben schon geschrieben ist git nuneinmal nicht vorher da gewesen, und die gründe für git, und gegen die anderen sind teils sehr subjektiv, und manche einfach eine Geschmacksfrage.
Tja, da muss man sich die Frage stellen, ob man git hätte ab die Canonical Bedürfnisse anpassen können, ohne dabei groß mit Upstream zu brechen. Wenn man in Betracht zieht, wer git entwickelt hat und unter wessen Schirmherrschaft es steht, dann möchte ich das doch stark bezweifeln.
>> Und es ist wohl kein Wunder warum sich um git coole Sachen wie github und gitorious entwickelt haben und um bzr nicht
http://launchpad.net
>> oder warum Python hg gewählt hat und nicht bzr .. ebenso Gnome, KDE, X, Kernel etc
Guido van Rossum (Python): "It's hard to explain my reasons for choosing -- like most language decisions (especially the difficult ones) it's mostly a matter of gut feelings."
Ja, da scheint es echt riesige Bedenken gegen bzr gegeben zu haben...
Einfach mal freuen, dass wir mind. 3 gute Versionsverwaltungssystem haben. Also in dem Bereich braucht man sich echt keine Sorgen zu machen.
Vielleicht kann man das gleiche über hg sagen aber bisher sah ich keinen Grund zu wechseln. Für hg spricht die Unterstützung durch Google Code und Bitbucket (So ein richtiger Fan von Launchpad bin ich nie geworden - obwohl das auch tolle Features hat).
Aus heutiger Sicht scheint git mehr für Leute zu sein, die Vorurteile gegenüber interpretierten Sprachen haben (also selbst eher zu den reinen C/C++ Entwicklern gehören) oder am Kernel rumbasteln wollen
Ansonsten finde ich git einfach angenehmer zum Arbeiten. Dinge wie das automatische Paging, die wunderbar kolorierten diffs, einfaches History rewriting (lokale branches rebasen, etc.) machen das Leben viel einfacher. Und die Kombination git-buildpackage + pristine-tar macht die Wartung von Debian Paketen extrem einfach. Hooks sind viel einfacher, und werden in .git/hooks im Repository gespeichert, anstatt außerhalb wie bei bzr. Sicherlich bietet auch bzr einige Vorteile, wie z.B. einen enormen Umfang an Meta-Informationen in commits wenn man welche reinschreibt und mehr.
Launchpad kann ja auch git repositories importieren und dann bzr repositories zur Verfügung stellen, was auch ganz nett ist. Außerdem müsste man auch mit bzr-git in der Lage sein, einen r/w Mirror zu erstellen, ausprobiert hab ich sowas aber noch nicht.
Anyway, beide funktionieren gut, beide haben ihre Vor- und Nachteile. Aber letztendlich muss sowieso jeder/jede der/die am Kernel oder GNOME hacked und gleichzeitig noch an Ubuntu mitarbeitet beides können. Und will er/sie noch an Python hacken, so muss er/sie auch noch Mercurial beherrschen
Tortoise hat selber ein Git Tool was ähnlich TortoiseSVN arbeitet rausgebracht und es gibt selbst ein Plugin für Visual Studio (Git Extension) und auch unter Linux und Mac gibt es recht vernüftige grafische Tools und selbst ein Plugin für Eclipse ist schon zu bekommen.
Es gibt im Grunde so 2 Sachen die unbedingt in Git rein müssten, damit es noch eine grössere Akzeptanz findet. Zum einen partielles auschecken und zum zweiten das auch leere Verzeichnisse akzeptiert werden. Das mit den Submodulen ist zwar mehr oder weniger als Workaround benutzbar aber gerade das ist ein Punkt der bei Subversion ja sehr gut und einfach funktioniert.
Bazaar wird von Canonical etwas gepusht und es ist auch gut mehrere Systeme zur Auswahl zu haben. Aber IMHO hat Git die momentan besseren Ansätze und das nicht nur im Bereich Performance. Wenn die GUI Tools noch besser werden und auch mehr Features von Git da unterstützt werden und zudem noch paar der oft gewünschten Features zukommen, ist Git eine richtig runde Sache.