Am Donnerstag, den 19.08.2010, 08:44 +0200 schrieb Arne Babenhauserheide: > Benjamin Kellermann wrote: > > der Fakt, dass es ganze > > Softwareprojekte gibt, die versuchen mehrere Repositories in sync zu > > halten sagt mir, dass es vielleicht doch etwas schwieriger ist als > > einfach nur ein post-push-hook… > > hg-git wird selbst mit genau so einem Modell entwickelt,
solange die history immer gerade bleibt und wir das nur benutzen, wie svn ohne branches denke ich auch, dass es geht. Wenn dann der erste heult, weil er 5 branches mit 4 commits und gerebasedter history auf einmal syncen will soll niemand sagen, ich hätte euch nicht gewarnt! Besser einen funktionierenden Server und wenn dann jemand mit hg-git, bzr-git, git-hg, bzr-hg, git-bzr oder hg-bzr rumspielen will, dann bitteschön… > >> Nachteil: Doppelter Platzbedarf. > > > > ich finde es komisch, dass immer alle so geil auf geringe repo-Größe und > > super Geschwindigkeiten sind. Es ist doch völlig Wurscht, ob ein Projekt > > den einfachen doppelten oder dreifachen Platzbedarf hat, wenn es > > Terrabyteplatten für lau gibt… > > Ich hätte es nicht vorgeschlagen, wenn ich den Nachteil hier für wirklich > relevant halten würde :) > > Das Problem an Geschwindigkeiten ist für mich, dass ein langsames Klonen > eine Barriere bildet, durch die neue Leute nur schwer einsteigen können. > Nach zu langer Wartezeit ist die Lust auf einen kurzen Fix oft wieder weg. coole Argumentationskette: A: das braucht viel Platz! B: hey, es gibt große Platten! A: Platz ist ein total wichtiges Argument, es ist nämlich doof, wenn das klonen langsam ist‽ Ben
