Re: Mercurial 0.4b vs git patchbomb benchmark

[Sean]

On Fri, April 29, 2005 2:01 am, Matt Mackall said:

> What I'd like to highlight here is that git's repo is growing more
> than 10 times faster. 52 megs is twice the size of a full kernel
> tarball. And that's going to be the bottleneck for network pull
> operations.

There isn't anything preventing optomized transfer protocols for git. 
Give it time.


> The fundamental problem I see with git is that the back-end has no
> concept of the relation between files. This data is only present in
> change nodes so you've got to potentially traverse all the commits to
> reconstruct a file's history. That's gonna be O(top-level changes)
> seeks. This introduces a number of problems:
>
> - no way to easily find previous revisions of a file
>   (being able to see when a particular change was introduced is a
>   pretty critical feature)

Scanning back through the history is a linear operation and will quite
likely be just fine for many uses.   As others have pointed out, you can
cache the result to improve subsequent lookups.


> - no way to do bandwidth-efficient delta transfer

There's nothing preventing this in the longer term.  And you know, we're
only talking about a few megabytes per release.  We're not talking about
video here.


> - no way to do efficient delta storage

This has been discussed.  It is a recognized and accepted design
trade-off.  Disk is cheap.


> - no way to do merges based on the file's history[1]

What is preventing merges from looking back through the git history?



The fundamental design of git is essentially done, it is what it is.

Your concearns are about performance rather than real limitations and it's
just too damn early in the development process for that.  Frankly it's
amazing how good git is considering its age; it's already _way_ faster and
easier to use than bk ever was for my use.


> Mathematics is the supreme nostalgia of our time.

I've been tying to figure out what this means for a while now <g>


Sean


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/