On 12/5/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> >>>>> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> So I tried a full history conversion using git-svn of the gcc
> Daniel> repository (IE every trunk revision from 1-HEAD as of
> Daniel> yesterday) The git-svn import was done using repacks every
> Daniel> 1000 revisions.  After it finished, I used git-gc --aggressive
> Daniel> --prune.  Two hours later, it finished.  The final size after
> Daniel> this is 1.5 gig for all of the history of gcc for just trunk.
>
> Most of the space is probably taken by the SVN specific data.

I showed a du of the pack directory.
Everyone tells me that svn specfic data is in .svn, so i am
disinclined to believe this.

Also, given that hg can store the svn data without this kind of
penalty, it's just another strike against git.


>  To get
> an idea of how GIT would handle GCC data, you should clone the GIT
> directory or checkout one from infradead.org:
Does infradead have the entire history?

>   % git clone git://git.infradead.org/gcc.git
>
> On my machine, it takes 856M with a checkout copy of trunk and
> contains the trunk, autovect, fixed-point, 4.1 and 4.2 branches. In
> comparaison, my checked out copy of trunk using SVN requires 1.2G, and
> I don't have any history around...

This is about git's usability and space usage, not SVN.
People say we should consider GIT. I have been considering GIT and hg,
and right now, GIT looks like a massive loser in every respect.
It's harder to use.
It takes up more space than hg to store the same data.
It requires manual repacking
it's diff/etc commands are not any faster.

Humorously, i tried to verify whether infradead has full history or
not, but of course git log git://git.infradead.org/gcc.git says
"fatal, not a git repository".
(though git clone is happy to clone it, because it is a git repository).
I'm sure there is some magic option or command line i need to use to
view remote log history without cloning the repository.
But all the other systems we look at don't require this kind of
bullshit to actually get things done.

As I said, maybe i'll look at git in another year or so.
But  i'm certainly going to ignore all the "git is so great, we should
move gcc to it" people until it works better, while i am much more
inclined to believe the "hg is so great, we should move gc to it"
people.

Reply via email to