Ich finde es erstaunlich, wie viele Projekte derzeit zu git migrieren. Ich bin selber auch von RCS über CVS und Subversion zu git gekommen und bin damit sehr zufrieden.
Ich denke dadurch, das es immer mehr Projekte benutzen kennen es einfach immer mehr Programmierer und wollen es auch für andere Projekte habe da sie die Vorteile sehen. Andererseits ist GIT mittlerweile einfach so ausgereift, das man es benutzen kann. Es gibt Portierungstool von SVN, grafische Oberflächen für alle wichtigen Betriebssysteme und haufenweise Dokumentation im Netz.
Sicherlich vom Linux Kernel. Der Hype hält ja schon eine Weile an.
DVCS sind ja allgemein ein interessantes Thema, gerade für Open Source Projekte. Die Entwicklung von Git hat das Thema enorm nach vorne gebracht, und entsprechend ist viel Aufmerksamkeit dorthin geflossen. Allerdings sind auch andere DVCS aktuell sehr beliebt, speziell Mercurial ist weit verbreitet, und in gewissen Grenzen auch Bazaar.
Und wieviele von den Projekten brauchen wirklich DVCS? Ich vermute starkt, dass der Wechsel nur dem Hype wegen ist und die technischen Nachteile gegenüber VCS nicht bewusst sind.
Welche Nachteile sollen das denn für ein FOSS Projekt sein? Bei der geschlossenen Entwicklung kann ich es ja noch verstehen, aber für FOSS sind verteilte Systeme wirklich Gold wert.
Welche Nachteile sollen das denn für ein FOSS Projekt sein?
DVCS verleiten Entwickler dazu in lokalen Branches/Clones zu arbeiten und dann in einem großen Commit/Merge alles in den Hauptzweig zu übernehmen.
Sehr ähnliche wie Codedumps von Firmen, die eigentlich nicht wollen, aber durch (L)GPL ihre Änderungen freigeben müssen.
Natürlich lässt sich das auch durch entsprechende Vorschriften vermeiden, aber die Einhaltung solcher Vorschriften zu kontrollieren bzw. im Verletzungsfall entsprechende Maßnahme zu setzen, dürfte für eine Entwicklergemeinschaft äußerst schwierig und kontroversiell sein.
Man kann das dann praktisch nur ähnlich wie beim Linux Kernel machen, wo eben nur sehr wenige in den "echten" Kernel schreiben dürfen. Aber selbst das ist für viele Gemeinschaften schwierig oder gar nicht umsetzbar.
DVCS verleiten Entwickler dazu in lokalen Branches/Clones zu arbeiten und dann in einem großen Commit/Merge alles in den Hauptzweig zu übernehmen.
Meiner Meinung nach ist das totale Gegenteil der Fall.
Ein DVCS bringt einen potentiellen externen Kontributor überhaupt erst in die Lage, ordentlich (mit Versionsgeschichte) entwickeln zu können, ohne Zugriff auf das Haupt-Repository haben zu müssen, und ohne Verwaltungs-Overhead. Ein DVCS, das zudem noch das Umschreiben der Geschichte zulässt (so wie Git), ermöglicht es außerdem, dass ein Kontributor seine eventuell wilde Entwicklung bereinigt und logisch gruppiert zum Review einreicht, anstatt als Code-Dump oder als wirrer Commit-Wald.
Gerade für diesen Anwendungsfall ist DVCS ideal geeignet, und SVN und Freunden haushoch überlegen. Bei SVN bleibt ja nur der Code-Dump übrig, oder das manuelle Arbeiten mit Patches (oder halt die Nutzung eines verteilten Systems wie Git oder früher Darcs als Aufsatz über SVN).
Ein DVCS bringt einen potentiellen externen Kontributor überhaupt erst in die Lage, ordentlich (mit Versionsgeschichte) entwickeln zu können, ohne Zugriff auf das Haupt-Repository haben zu müssen, und ohne Verwaltungs-Overhead.
Schon klar, das wollte ich auch nicht in Frage stellen. Ich habe auch mit git noch keine sehr große Erfahrung, aber bisher sah es für mich so aus, als würden Entwickler damit die Möglichkeit haben, große Mengen an Commits auf ein Mal von einem bisher unbekannten (weil lokalen) Clone in den Hauptzweig zu überführen.
Eben ein Art Codedump, d.h. viele Änderungen auf einmal anstatt alle paar Stunden oder Tage kleine Änderungen.
Fürs Herumexperimentieren ist sowas natürlich große Klasse, aber es fördert halt nicht gerade das gemeinschaftliche Arbeiten. Wie gesagt kann man da sicher mit entsprechenden Regelungen nachbesser, aber ideal ist das nicht.
als würden Entwickler damit die Möglichkeit haben, große Mengen an Commits auf ein Mal von einem bisher unbekannten (weil lokalen) Clone in den Hauptzweig zu überführen.
Die Entwickler haben die Möglichkeit, das zu tun, was sie tun wollen.
Nehmen wir mal an, ein externer Kontributor hat eine sehr große Änderung vorgenommen, und möchte gerne, dass diese im Repository aufgenommen wird.
Wenn das Repository ein zentrales System wie SVN/CVS benutzt, ist die Wahrscheinlichkeit hoch, dass dieser Code-Beitrag als einziger, riesengroßer, nicht-reviewbarer Patch kommt. Alternativ kommt er als sehr viele kleine einzel-Patches, die es manuell zu behandelt gilt. Beides ist nicht effektiv.
Wie siehts bei einem DVCS aus? Der Kontributor hat irgendwann mal das offizielle Repo geklont, und dann damit in seinem eigenen Branch gearbeitet. Jetzt möchte er, dass sein Topic-Branch gemerged wird. Dazu macht er seinen Branch irgendwie verfügbar (eigener Server, Github und Freunde, per E-Mail (git-format-patch, git-am), oder wie auch immer). Upstream kann jetzt entscheiden, was sie tun wollen. Im einfachsten Fall würden sie den Branch hinzufügen und mergen. Sie könnten aber auch die Commits auf den momentanen HEAD setzen. Oder sie organisieren die Commits um, kondensieren einige ("sqashen" mehrere Commits zu einem zusammen), ändern die Reihenfolge, passen einzelne Commits an, oder was auch immer. All das müssen sie nicht manuell machen, sondern werden vom System unterstützt.
Vieles von deinem beschriebenen Mergen aus einem separaten Branch kann Subversion auch. Und der Rest wird Subversion wahrscheinlich in 2 Jahren auch können.
Nehmen wir mal an, ein externer Kontributor hat eine sehr große Änderung vorgenommen, und möchte gerne, dass diese im Repository aufgenommen wird.
Wir gehen von unterschiedlichen Ausgangslagen aus.
Natürlich ist es fein, wenn ein Neuer schon mal zu Hause entwickeln kann, bis er sich sicher ist, dass er damit an das Projekt herantreten will. Keine Frage!
Es geht mir mehr darum, wie verhindert werden kann, dass die bereits beitragenden Entwickler sowas tun. Bei einem zentralen VCS hat man z.B als Maintainer oder interessierter Mitentwickler die Möglichkeit, die eingehenden Änderungen zeitlich nahe mitzuverfolgen. Schon git-svn hat gezeigt, dass sowas verloren geht, d.h. Entwickler dann ganze Serien von Commits auf einmal übernehmen. Der Maintainer hat dann alle auf einmal zu kontrollieren.
Im Falle von git dann halt entweder alles auf einmal kontrollieren, oder alle anstehenden Änderungen von fremden Clonen herholen.
Es geht mir mehr darum, wie verhindert werden kann, dass die bereits beitragenden Entwickler sowas tun.
Du versuchst, ein soziales Problem mit technischen Mitteln zu lösen. Was, wie du am Beispiel git-svn schon selbst gezeigt hast, im Voraus zum Scheitern verurteilt ist.
Im Falle von git dann halt entweder alles auf einmal kontrollieren, oder alle anstehenden Änderungen von fremden Clonen herholen.
Git lässt sich ebenfalls auf zentrale Art benutzen, d.h. es gibt ein einziges "blessed" Repository, in das alle registrierten Entwickler committen können. So wird es auch bei den meisten Projekten genutzt, die auf Git umgestiegen sind. Die Vorteile eines dezentralen Systems bleiben dadurch erhalten.
Du versuchst, ein soziales Problem mit technischen Mitteln zu lösen.
Nein, ich schrieb bereits, dass ein Strom überschaubarer Änderungen vermutlich nur mehr über Verhaltensregeln machbar ist.
Was im Grunde darin resultiert, dass nur mehr die jeweiligen Maintainer committen dürfen und der nur mehr Sachen übernimmt, die von mindestens einem weiteren Entwickler kontrolliert wurden.
DVCS sind halt sehr gut für jeder arbeiten an seinem Teil des ganzen, aber eben schlechter für mehrere arbeiten am selben Teil.
Hat eben alles sein Vor- und Nachteile und dort wo die Technik unzureichend ist, muss man eben andere Mechanismen finden, um entsprechende Resultate zu erhalten
Nein, ich schrieb bereits, dass ein Strom überschaubarer Änderungen vermutlich nur mehr über Verhaltensregeln machbar ist.
Du schriebst es bereits, und ich habe dir bereits widersprochen. Du wirst außerdem von der Realität überholt. Es sind mittlerweile viele Projekte auf DVCS' umgestiegen, und das von dir befürchtete Problem habe ich noch nirgends beobachtet.
Es gehört zum natürlichen Selbsterhaltungstrieb der Entwickler, dass sie ihre Änderungen möglichst schnell in das "blessed" Repo überführen wollen - denn sonst wird die Wartung der eigenen Änderungen ständig komplizierter.
DVCS sind halt sehr gut für jeder arbeiten an seinem Teil des ganzen, aber eben schlechter für mehrere arbeiten am selben Teil.
Auch hier bist du meiner Erfahrung nach von der Realität überholt worden. Ich glaube nicht, dass das KDE Projekt hier mehr Probleme hätte als z.B. GNOME (die vor ca 1.5 Jahren umgestiegen sind, und sehr gute Erfahrungen damit gemacht haben).
Hat eben alles sein Vor- und Nachteile und dort wo die Technik unzureichend ist
Was uns wieder zur ursprünglichen Frage zurückführt, die war: "Welche Nachteile hat ein DVCS für ein Open Source Projekt?" Deine Antwort ist offensichtlich: Ein DVCS ist so vielseitig verwendbar, dass jemand damit auch Blödsinn machen könnte.
> Es geht mir mehr darum, wie verhindert werden kann, dass die bereits > beitragenden Entwickler sowas tun. Wieso willst Du sowas verhindern? Lass sie doch lokal entwickeln am Ende einen einzigen großen Patch einchecken, solange ihre lokale Historie Bestandteil des Hauptrepositories wird.
Sehe ich genau anders herum. Dadurch das es den pull-Mechanismus gibt, kann jeder selbst entscheiden wann, was und wie er merget.
Das ist natürlich cool. Ich bin bisher davon ausgegangen, dass lokale Clone völlig getrennt sind. Aber wenn sie natürlich weiterhin allen Beteiligten am Hauptzweig Benachrichtigungen über Änderungen zur Verfügung stellen und man jederzeit als Entwickler die Möglichkeit hat, von diesen lokalen Clones mit pull Änderungen zu beziehen, hat sich die Sache erledigt.
Ich frage mich nur, wie das z.B. auf meinem System klappt. Wenn ich einen Clone eines git Repositories gemacht habe und lokale Änderunge committe, scheint das an der Quelle niemand mit zu bekommen. Wäre auch interessant, wie die Entwickler der Quelle so ohne mein Einverständnis durch meine Firewall meine Änderungen holen könnten.
Gibt es dazu irgend ein Referenzmaterial, das man gelesen haben sollte? Besonders diese automatische durchtunneln von Sicherheitsbarrieren scheint mit schon ein bischen gefährlich
Auf deine lokale Festplatte können sie natürlich nicht zugreifen, wäre ja noch schöner! Aber i.d.R. machst du nicht nur einen lokalen clone sondern du veröffentlichst deine Arbeit z.B. auf github, gitorious od. bitbucket (wenn du hg statt git nutzt). Diese Plattformen haben auch ein spezielles clone Feature über welches du ein anderes Projekt das dort gehostet wird clonen kannst. Dann wird auch der Eigentümer des Projekts benachrichtigt. Auch bieten diese Hosting-Sites merge/pull Requests mit nettem GUI. Sehr praktisch.
Wenn du willst kannst du aber auch ein eigenes Repo hosten. Z.B. per ssh (aber da muss man ja user anlegen) oder per http. Mit mercurial (hg) get letzteres sehr einfach. Da kann man ein winziges Python CGI-Script in einen public html Ordner legen und z.B. per htaccess den Zugriff darauf regeln. Alternativ kann man mit hg auch per `hg serve´ gleich einen Webserver starten. Diese beiden Webmöglichkeiten bei hg sind auch gleich ein weg um zu pushen (falls konfiguriert) bzw. zu pullen (immer). Ich glaub mit git ist das etwas komplizierter, denn es gibt (nicht-ssh) git repos die kein Webinterface bieten. Bei hg ist immer autom. an der *selben* URL ein Webinterface zu finden. Aber im Großen und Ganzen gibts kaum Unterschied zw. git und hg. Verwende beides.
Davon abgesehen gibts jederzeit die Möglichkeit, Email-Patches zu erzeugen und an die entsprechenden Mailing-Listen zu schicken. Siehe git-format-patch(1), git-send-email(1), git-am(1).
Ja aber wer bitte macht nur einen lokalen Clone? Man pusht immer auch in ein guthub/gitorious/... Repo. Schon allein um einfach überall daran Arbeiten zu können bzw. ein Backup zu haben.
Hör dir die Chaosradio Express Sendung über git an. Da wird u.a. auch gesagt, dass erst mit DSCM/DVCS die Entwicklung *wirklich* Open Source wird, weil dann eben auch der Workflow offen ist. Damit kanns't du einen Fork mit einen Befehl machen und hast die ganze Revisionshistory des Ursprungprojekts! Und damit sind dann auch Cross-Fork Merges möglich! In der Tat gibt es damit keinen großen unterschied zw. einen Fork und einen Branch mehr.
Das mergen ist bei DVCS, zumindest bei git und mercurial, einfacher als bei SVN und CVS - zumindest aus meiner Sicht. Allerdings habe ich das schon häufiger von anderen Entwicklern ebenfalls gehört. Insofern wäre das schon ein direkter Vorteil; mehr oder minder unabhängig vom "D"
Die Frage ist falsch. Richtig wäre: Wie viele Projekte brauchen wirklich ein zentrales VCS? So wie ich das sehe, sind die einzigen Vorteile von SVN das Locken von Dateien/Branches und Benutzerrechte auf diese.
Git kann man auch als einen zentrales VCS nutzen, muss es aber nicht. Es fehlt halt das Locken, weil man dafür einen eindeutigen zentralen Server braucht. Mit gitolite http://github.com/sitaramc/gitolite kannst du auch Zugriffsrechte auf Branches vergeben. Wenn man es braucht, aber man kann ja auch einfach ein neues Projekte erstellen und mit git-submodule arbeiten.
Ein anderer Vorteil: Bei SVN klont man nicht die ganze History und somit sind riesige Binärdatein kein Problem. Zumindest bei hg sind die Plugins zum Beschränken des Klonens (beschr. auf gewisse Revisionen bzw. auf gewisse Verzeichnisse) nicht final.
Zum einen hat es einen enormen Vorteil die gesamte History lokal zur Verfügung zu haben. Zum anderen, wieso man überhaupt Binärdateien in einem VCS haben möchte kann man auch gerne diskutieren.
Da melden sich dann normal weise die Spielentwickler, die ihre in einer riesigen Datei zusammengefassten Texturen oder Videos zum Spiel auch im VCS haben möchten. Wozu das auch immer gut ist, als ob sie sie mergen oder diffs machen können.
Ich habe zwar auch gerne Odf, Pdfs, Bilder im VCS, aber das sind immer sehr kleine Dateien. Du willst doch nicht ernsthaft ein Video von 60 Minuten in einem VCS haben?
Ich brauch das nicht. Aber egal wie sinnvoll es ist, das ist eben etwas was so DVCSe nicht (gut/sinnvoll) können und somit kann man Leuten die das unbedingt wollen das nicht "verkaufen". Z.B. blender hat sau viele Binärdateien im SVN Repo (DLLs von libs die sie verwenden kompiliert für jede mögl. Plattform). Das Repo ist in hg konvertiert ca. 9 GB groß!
Um sein HOME zu versionieren, scheint ein DVCS ja nicht unbedingt nötig, andererseits - wenn es ein gutes Werkzeug ist, muss es ja auch nicht schaden ... Dazu fällt mir ein, dass git bei großen Dateien sehr langsam sein soll (und Linus mal meinte, er wisse auch nicht, was man dagegen tun könne) - weiß jemand, wie das bei mercurial aussieht?
Man kann schon was dagegen machen, die Dateien zerlegen. Aber dann ist man schwubbdiewubb dabei BtrFS nachzuimplemtieren. Warum also nicht gleich das benutzen?
Git ist einfach spitze, schoen das KDE jetzt auch git benutzt. Bei uns an der Uni nutzen alle SVN das ist einfach nur ein krampf.
Ich finde es erstaunlich, wie viele Projekte derzeit zu git migrieren. Ich bin selber auch von RCS über CVS und Subversion zu git gekommen und bin damit sehr zufrieden.
Aber woher kommt jetzt der Hype?
Ich denke dadurch, das es immer mehr Projekte benutzen kennen es einfach immer mehr Programmierer und wollen es auch für andere Projekte habe da sie die Vorteile sehen.
Andererseits ist GIT mittlerweile einfach so ausgereift, das man es benutzen kann. Es gibt Portierungstool von SVN, grafische Oberflächen für alle wichtigen Betriebssysteme und haufenweise Dokumentation im Netz.
"Aber woher kommt jetzt der Hype?"
Sicherlich vom Linux Kernel. Der Hype hält ja schon eine Weile an.
DVCS sind ja allgemein ein interessantes Thema, gerade für Open Source Projekte. Die Entwicklung von Git hat das Thema enorm nach vorne gebracht, und entsprechend ist viel Aufmerksamkeit dorthin geflossen.
Allerdings sind auch andere DVCS aktuell sehr beliebt, speziell Mercurial ist weit verbreitet, und in gewissen Grenzen auch Bazaar.
Und wieviele von den Projekten brauchen wirklich DVCS? Ich vermute starkt, dass der Wechsel nur dem Hype wegen ist und die technischen Nachteile gegenüber VCS nicht bewusst sind.
Welche Nachteile sollen das denn für ein FOSS Projekt sein? Bei der geschlossenen Entwicklung kann ich es ja noch verstehen, aber für FOSS sind verteilte Systeme wirklich Gold wert.
DVCS verleiten Entwickler dazu in lokalen Branches/Clones zu arbeiten und dann in einem großen Commit/Merge alles in den Hauptzweig zu übernehmen.
Sehr ähnliche wie Codedumps von Firmen, die eigentlich nicht wollen, aber durch (L)GPL ihre Änderungen freigeben müssen.
Natürlich lässt sich das auch durch entsprechende Vorschriften vermeiden, aber die Einhaltung solcher Vorschriften zu kontrollieren bzw. im Verletzungsfall entsprechende Maßnahme zu setzen, dürfte für eine Entwicklergemeinschaft äußerst schwierig und kontroversiell sein.
Man kann das dann praktisch nur ähnlich wie beim Linux Kernel machen, wo eben nur sehr wenige in den "echten" Kernel schreiben dürfen.
Aber selbst das ist für viele Gemeinschaften schwierig oder gar nicht umsetzbar.
Ein DVCS bringt einen potentiellen externen Kontributor überhaupt erst in die Lage, ordentlich (mit Versionsgeschichte) entwickeln zu können, ohne Zugriff auf das Haupt-Repository haben zu müssen, und ohne Verwaltungs-Overhead. Ein DVCS, das zudem noch das Umschreiben der Geschichte zulässt (so wie Git), ermöglicht es außerdem, dass ein Kontributor seine eventuell wilde Entwicklung bereinigt und logisch gruppiert zum Review einreicht, anstatt als Code-Dump oder als wirrer Commit-Wald.
Gerade für diesen Anwendungsfall ist DVCS ideal geeignet, und SVN und Freunden haushoch überlegen. Bei SVN bleibt ja nur der Code-Dump übrig, oder das manuelle Arbeiten mit Patches (oder halt die Nutzung eines verteilten Systems wie Git oder früher Darcs als Aufsatz über SVN).
Schon klar, das wollte ich auch nicht in Frage stellen.
Ich habe auch mit git noch keine sehr große Erfahrung, aber bisher sah es für mich so aus, als würden Entwickler damit die Möglichkeit haben, große Mengen an Commits auf ein Mal von einem bisher unbekannten (weil lokalen) Clone in den Hauptzweig zu überführen.
Eben ein Art Codedump, d.h. viele Änderungen auf einmal anstatt alle paar Stunden oder Tage kleine Änderungen.
Fürs Herumexperimentieren ist sowas natürlich große Klasse, aber es fördert halt nicht gerade das gemeinschaftliche Arbeiten. Wie gesagt kann man da sicher mit entsprechenden Regelungen nachbesser, aber ideal ist das nicht.
Nehmen wir mal an, ein externer Kontributor hat eine sehr große Änderung vorgenommen, und möchte gerne, dass diese im Repository aufgenommen wird.
Wenn das Repository ein zentrales System wie SVN/CVS benutzt, ist die Wahrscheinlichkeit hoch, dass dieser Code-Beitrag als einziger, riesengroßer, nicht-reviewbarer Patch kommt. Alternativ kommt er als sehr viele kleine einzel-Patches, die es manuell zu behandelt gilt. Beides ist nicht effektiv.
Wie siehts bei einem DVCS aus? Der Kontributor hat irgendwann mal das offizielle Repo geklont, und dann damit in seinem eigenen Branch gearbeitet. Jetzt möchte er, dass sein Topic-Branch gemerged wird. Dazu macht er seinen Branch irgendwie verfügbar (eigener Server, Github und Freunde, per E-Mail (git-format-patch, git-am), oder wie auch immer). Upstream kann jetzt entscheiden, was sie tun wollen. Im einfachsten Fall würden sie den Branch hinzufügen und mergen. Sie könnten aber auch die Commits auf den momentanen HEAD setzen. Oder sie organisieren die Commits um, kondensieren einige ("sqashen" mehrere Commits zu einem zusammen), ändern die Reihenfolge, passen einzelne Commits an, oder was auch immer. All das müssen sie nicht manuell machen, sondern werden vom System unterstützt.
Vieles von deinem beschriebenen Mergen aus einem separaten Branch kann Subversion auch. Und der Rest wird Subversion wahrscheinlich in 2 Jahren auch können.
Vielleicht hast du nicht mitbekommen, dass ich von externen Kontributoren sprach, die keinen schreibenden Zugriff auf das Upstream-Repository haben.
Wir gehen von unterschiedlichen Ausgangslagen aus.
Natürlich ist es fein, wenn ein Neuer schon mal zu Hause entwickeln kann, bis er sich sicher ist, dass er damit an das Projekt herantreten will.
Keine Frage!
Es geht mir mehr darum, wie verhindert werden kann, dass die bereits beitragenden Entwickler sowas tun.
Bei einem zentralen VCS hat man z.B als Maintainer oder interessierter Mitentwickler die Möglichkeit, die eingehenden Änderungen zeitlich nahe mitzuverfolgen.
Schon git-svn hat gezeigt, dass sowas verloren geht, d.h. Entwickler dann ganze Serien von Commits auf einmal übernehmen. Der Maintainer hat dann alle auf einmal zu kontrollieren.
Im Falle von git dann halt entweder alles auf einmal kontrollieren, oder alle anstehenden Änderungen von fremden Clonen herholen.
Nein, ich schrieb bereits, dass ein Strom überschaubarer Änderungen vermutlich nur mehr über Verhaltensregeln machbar ist.
Was im Grunde darin resultiert, dass nur mehr die jeweiligen Maintainer committen dürfen und der nur mehr Sachen übernimmt, die von mindestens einem weiteren Entwickler kontrolliert wurden.
DVCS sind halt sehr gut für jeder arbeiten an seinem Teil des ganzen, aber eben schlechter für mehrere arbeiten am selben Teil.
Hat eben alles sein Vor- und Nachteile und dort wo die Technik unzureichend ist, muss man eben andere Mechanismen finden, um entsprechende Resultate zu erhalten
Es gehört zum natürlichen Selbsterhaltungstrieb der Entwickler, dass sie ihre Änderungen möglichst schnell in das "blessed" Repo überführen wollen - denn sonst wird die Wartung der eigenen Änderungen ständig komplizierter.
Auch hier bist du meiner Erfahrung nach von der Realität überholt worden. Ich glaube nicht, dass das KDE Projekt hier mehr Probleme hätte als z.B. GNOME (die vor ca 1.5 Jahren umgestiegen sind, und sehr gute Erfahrungen damit gemacht haben).Was uns wieder zur ursprünglichen Frage zurückführt, die war: "Welche Nachteile hat ein DVCS für ein Open Source Projekt?" Deine Antwort ist offensichtlich: Ein DVCS ist so vielseitig verwendbar, dass jemand damit auch Blödsinn machen könnte.> Es geht mir mehr darum, wie verhindert werden kann, dass die bereits
> beitragenden Entwickler sowas tun.
Wieso willst Du sowas verhindern? Lass sie doch lokal entwickeln am Ende einen einzigen großen Patch einchecken, solange ihre lokale Historie Bestandteil des Hauptrepositories wird.
lg
Erik
Sehe ich genau anders herum. Dadurch das es den pull-Mechanismus gibt, kann jeder selbst entscheiden wann, was und wie er merget.
Das ist natürlich cool. Ich bin bisher davon ausgegangen, dass lokale Clone völlig getrennt sind.
Aber wenn sie natürlich weiterhin allen Beteiligten am Hauptzweig Benachrichtigungen über Änderungen zur Verfügung stellen und man jederzeit als Entwickler die Möglichkeit hat, von diesen lokalen Clones mit pull Änderungen zu beziehen, hat sich die Sache erledigt.
Ich frage mich nur, wie das z.B. auf meinem System klappt. Wenn ich einen Clone eines git Repositories gemacht habe und lokale Änderunge committe, scheint das an der Quelle niemand mit zu bekommen. Wäre auch interessant, wie die Entwickler der Quelle so ohne mein Einverständnis durch meine Firewall meine Änderungen holen könnten.
Gibt es dazu irgend ein Referenzmaterial, das man gelesen haben sollte?
Besonders diese automatische durchtunneln von Sicherheitsbarrieren scheint mit schon ein bischen gefährlich
Auf deine lokale Festplatte können sie natürlich nicht zugreifen, wäre ja noch schöner! Aber i.d.R. machst du nicht nur einen lokalen clone sondern du veröffentlichst deine Arbeit z.B. auf github, gitorious od. bitbucket (wenn du hg statt git nutzt). Diese Plattformen haben auch ein spezielles clone Feature über welches du ein anderes Projekt das dort gehostet wird clonen kannst. Dann wird auch der Eigentümer des Projekts benachrichtigt. Auch bieten diese Hosting-Sites merge/pull Requests mit nettem GUI. Sehr praktisch.
Wenn du willst kannst du aber auch ein eigenes Repo hosten. Z.B. per ssh (aber da muss man ja user anlegen) oder per http. Mit mercurial (hg) get letzteres sehr einfach. Da kann man ein winziges Python CGI-Script in einen public html Ordner legen und z.B. per htaccess den Zugriff darauf regeln. Alternativ kann man mit hg auch per `hg serve´ gleich einen Webserver starten. Diese beiden Webmöglichkeiten bei hg sind auch gleich ein weg um zu pushen (falls konfiguriert) bzw. zu pullen (immer). Ich glaub mit git ist das etwas komplizierter, denn es gibt (nicht-ssh) git repos die kein Webinterface bieten. Bei hg ist immer autom. an der *selben* URL ein Webinterface zu finden. Aber im Großen und Ganzen gibts kaum Unterschied zw. git und hg. Verwende beides.
Davon abgesehen gibts jederzeit die Möglichkeit, Email-Patches zu erzeugen und an die entsprechenden Mailing-Listen zu schicken. Siehe git-format-patch(1), git-send-email(1), git-am(1).
Hab ich nicht erwähnt weil es schon irgendwo anders in diesem Thread erwähnt wurde (bzw. in einen Branch des Threads).
Ah, hatte ich mir schon gedacht.
Dann ist der Kommentar von rübezahl gegenstandslos, immerhin ging es um eben diese lokalen Clone.
Ja aber wer bitte macht nur einen lokalen Clone? Man pusht immer auch in ein guthub/gitorious/... Repo. Schon allein um einfach überall daran Arbeiten zu können bzw. ein Backup zu haben.
Hör dir die Chaosradio Express Sendung über git an. Da wird u.a. auch gesagt, dass erst mit DSCM/DVCS die Entwicklung *wirklich* Open Source wird, weil dann eben auch der Workflow offen ist. Damit kanns't du einen Fork mit einen Befehl machen und hast die ganze Revisionshistory des Ursprungprojekts! Und damit sind dann auch Cross-Fork Merges möglich! In der Tat gibt es damit keinen großen unterschied zw. einen Fork und einen Branch mehr.
Wer neue Entwickler und deren Arbeit leicht einbauen will, braucht es. Das ist kein Hype, das ist evolutionärer Druck.
Das mergen ist bei DVCS, zumindest bei git und mercurial, einfacher als bei SVN und CVS - zumindest aus meiner Sicht. Allerdings habe ich das schon häufiger von anderen Entwicklern ebenfalls gehört. Insofern wäre das schon ein direkter Vorteil; mehr oder minder unabhängig vom "D"
Die Frage ist falsch. Richtig wäre: Wie viele Projekte brauchen wirklich ein zentrales VCS? So wie ich das sehe, sind die einzigen Vorteile von SVN das Locken von Dateien/Branches und Benutzerrechte auf diese.
Git kann man auch als einen zentrales VCS nutzen, muss es aber nicht. Es fehlt halt das Locken, weil man dafür einen eindeutigen zentralen Server braucht. Mit gitolite http://github.com/sitaramc/gitolite kannst du auch Zugriffsrechte auf Branches vergeben. Wenn man es braucht, aber man kann ja auch einfach ein neues Projekte erstellen und mit git-submodule arbeiten.
Ein anderer Vorteil: Bei SVN klont man nicht die ganze History und somit sind riesige Binärdatein kein Problem. Zumindest bei hg sind die Plugins zum Beschränken des Klonens (beschr. auf gewisse Revisionen bzw. auf gewisse Verzeichnisse) nicht final.
Zum einen hat es einen enormen Vorteil die gesamte History lokal zur Verfügung zu haben.
Zum anderen, wieso man überhaupt Binärdateien in einem VCS haben möchte kann man auch gerne diskutieren.
Da melden sich dann normal weise die Spielentwickler, die ihre in einer riesigen Datei zusammengefassten Texturen oder Videos zum Spiel auch im VCS haben möchten. Wozu das auch immer gut ist, als ob sie sie mergen oder diffs machen können.
Ich habe zwar auch gerne Odf, Pdfs, Bilder im VCS, aber das sind immer sehr kleine Dateien. Du willst doch nicht ernsthaft ein Video von 60 Minuten in einem VCS haben?
Ich brauch das nicht. Aber egal wie sinnvoll es ist, das ist eben etwas was so DVCSe nicht (gut/sinnvoll) können und somit kann man Leuten die das unbedingt wollen das nicht "verkaufen". Z.B. blender hat sau viele Binärdateien im SVN Repo (DLLs von libs die sie verwenden kompiliert für jede mögl. Plattform). Das Repo ist in hg konvertiert ca. 9 GB groß!
Mit git auch "final" möglich, einfach --depth benutzen.
Um sein HOME zu versionieren, scheint ein DVCS ja nicht unbedingt nötig, andererseits - wenn es ein gutes Werkzeug ist, muss es ja auch nicht schaden ...
Dazu fällt mir ein, dass git bei großen Dateien sehr langsam sein soll (und Linus mal meinte, er wisse auch nicht, was man dagegen tun könne) - weiß jemand, wie das bei mercurial aussieht?
Man kann schon was dagegen machen, die Dateien zerlegen. Aber dann ist man schwubbdiewubb dabei BtrFS nachzuimplemtieren. Warum also nicht gleich das benutzen?
RCS oder so?
http://lmgtfy.com/?q=git+gnome