Benjamin Kellermann wrote: > Am Mittwoch, den 18.08.2010, 19:45 +0200 schrieb Arne Babenhauserheide: >> Idee aus IRC: sowohl hg als auch git auf dem server, und übertragen. > > ich denke nicht, dass das so eine gute Idee ist. Es gibt schon Projekte, > die sich genau damit befassen (z.B. tailor). Und 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, und nachdem das Problem keins von hg-git war, sondern eins von meinem lokalen Python-Setup, macht mir das deutlich weniger Sorgen. Und da hg-git auch ein Projekt ist, sehe ich den großen Unterschied von tailor nicht :) (außer halt, dass hg-git nur für Mercurial und Git funktioniert) hg-git bietet ein transparentes mapping. Das heißt, für jeden commit in git gibt es einen in hg und umgekehrt, und hg-git weiß, welcher zu welchem gehört. Dar Nachteil ist normalerweise, dass es recht lange dauert, ein großes Git- repo mit hg zu klonen (ich habe gestern ein 17.000 changeset repo getestet¹, und das braucht mehrere Stunden, weil halt jeder commit von git in hg konvertiert werden muss). Der verschwindet aber, wenn es beide repos gibt, die synchron gehalten werden. Dann können beide von ihrem nativen Format klonen und sind entsprechend schnell. ¹: Das freenet repository, um es in freenet zu spiegeln, so dass Leute anonym darauf zugreifen können. Geht über infokalypse recht einfach und effizient. >> 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. Von der commit- und update-Geschwindigkeit her sind alle DVCSs problemlos zu nutzen. Liebe Grüße, Arne PS: Für Leute, die beim Log gerne einen pager hätten: ~/.hgrc: [pager] pager = LESS='FSRX' less # quiet = True [extensions] pager = → http://mercurial.selenic.com/wiki/PagerExtension
