On Sun, Oct 26, 2008 at 9:07 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > I'm not sure if Mercurial mailing list is not subscribe only. Git isn't. > > On Sun, 26 Sep 2008, Felipe Contreras wrote: >> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> > [Cc: gmane.comp.version-control.git, >> > gmane.comp.version-control.mercurial.general] > >> > 3. Repository design and performance. > >> > Git and Mercurial have similar performance, although it is thought >> > that due to design Mercurial has faster patch applying and is >> > optimized for cold cache case, while Git has faster merging and is >> > optimized for warm cache case. >> > >> > Mercurial may have (or had) problems with larger binary files, from >> > what I have heard. >> >> The fact that hg is changeset based means that certain operations are >> slower, like checkout a specific commit. In hg my bet is you would >> need to gather a bunch of changesets while in git the operation is >> done in a single step. > > Actually from what I have read Mercurial stores current version > (snapshot) from time to time, so time to resolve specific commit is > limited. Also if you have packed your Git repository (good idea not > only to limit size, but also for performance (I/O performance)), then > resolving specific commit also might require some delta resolution > (by default delta chain length is limited to 50, see pack.depth). Ah, ok, good to know. >> It also means that bare clones are not possible in hg, or at least >> very complicated. > > I think it is things like .hgtags which make bare clones (without > working directory) to be hard or even impossible in Mercurial. Oops, I meant shallow clones (git clone --depth=1). -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
