Re: Mercurial 0.4b vs git patchbomb benchmark
- From
- Matt Mackall <mpm@selenic.com>
- Date
- May 2, 2005, 22:30 UTC
- Message-ID
- <20050502223002.GP21897@waste.org>
- In-Reply-To
- <Pine.LNX.4.58.0505021457060.3594@ppc970.osdl.org>
On Mon, May 02, 2005 at 03:02:16PM -0700, Linus Torvalds wrote:
Show 15 quoted lines
> > > On Mon, 2 May 2005, Bill Davidsen wrote: > > > > If there is a functional reason to use git, something Mercurial doesn't > > do, then developers will and should use git. But the associated hassles > > with large change size, rather than the absolute size, are worth > > considering. > > Note that we discussed this early on, and the issues with full-file > handling haven't changed. It does actually have real functional > advantages: > > - you can share the objects freely between different trees, never > worrying about one tree corrupting another trees object by mistake.
Not sure if this is terribly useful. It just makes it harder to pull the subset you're interested in.
> - you can drop old objects.
You can't drop old objects without dropping all the changesets that refer to them or otherwise being prepared to deal with the broken links.
> delta models very fundamentally don't support this.
The latter can be done in a pretty straightforward manner in mercurial with one pass over the data. But I have a goal to make keeping the whole history cheap enough that no one balks at it.
Show 5 quoted lines
> For example, a simple tree re-linker will work on any mirror site, and > work reliably, even if I end up uploading new objects with some tool that > doesn't know to break hardlinks etc. That can easily be much more than a > 10x win for a git repository site (imagine something like bkbits.net, but > got git).
What is a tree re-linker? Finds duplicate files and hard-links them? Ok, that makes some sense. But it's a win on one machine and a lose everywhere else.
> Whether it is a huge deal or not, I don't know. I do know that the big > deal to me is just the simplicity of the git object models. It makes me > trust it, even in the presense of inevitable bugs. It's a very safe model, > and right now safe is good.
I've added an "hg verify" command to Mercurial. It doesn't attempt to fix anything up yet, but it can catch a couple things that git probably can't (like file revisions that aren't owned by any changeset), namely because there's more metadata around to look at.
I'll probably post an updated version tomorrow, I'm beginning to work on a git2hg script.
-- Mathematics is the supreme nostalgia of our time.