>Yeah, I'm facing the same issue. I started playing with git last
>night. Apart from disk-space usage, it's very nice, though I really
>hope someone puts together a web-interface on top of git soon so we
>can seek what changed when and by whom.
Disk space issues? A complete git repository of the Linux kernel with
all changesets back to 2.4.0 takes just over 3G ... which is big compared
to BK, but 3G of disk only costs about $1 (for IDE ... if you want 15K rpm
SCSI, then you'll pay a lot more). Network bandwidth is likely to be a
bigger problem.
There's a prototype web i/f at http://grmso.net:8090/ that's already looking
fairly slick.
-Tony
>>>>> On Thu, 21 Apr 2005 10:41:52 -0700, "Luck, Tony" <[email protected]> said:
Tony> Disk space issues? A complete git repository of the Linux
Tony> kernel with all changesets back to 2.4.0 takes just over 3G
Tony> ... which is big compared to BK, but 3G of disk only costs
Tony> about $1 (for IDE ... if you want 15K rpm SCSI, then you'll
Tony> pay a lot more). Network bandwidth is likely to be a bigger
Tony> problem.
Ever heard that data is a gas? My disks always fill up in no time at
all, no matter how big they are. I agree that network bandwidth is an
bigger issue, though.
Tony> There's a prototype web i/f at http://grmso.net:8090/ that's
Tony> already looking fairly slick.
Indeed. Plus it has a cool name, too. Thanks for the pointer.
--david
Luck, Tony wrote:
>>Yeah, I'm facing the same issue. I started playing with git last
>>night. Apart from disk-space usage, it's very nice, though I really
>>hope someone puts together a web-interface on top of git soon so we
>>can seek what changed when and by whom.
>
>
> Disk space issues? A complete git repository of the Linux kernel with
> all changesets back to 2.4.0 takes just over 3G ... which is big compared
> to BK, but 3G of disk only costs about $1 (for IDE ... if you want 15K rpm
> SCSI, then you'll pay a lot more). Network bandwidth is likely to be a
> bigger problem.
>
That said, is there any plan to change how this functions in the future
to solve these problems? I.e. have it not use so much diskspace and
thus use less bandwith. Am I misunderstanding in assuming that after
say 1000 commits go into the tree it could end up several megs or gigs
bigger?
If that is the case might it not be more prudent to sort this out now?
> There's a prototype web i/f at http://grmso.net:8090/ that's already looking
> fairly slick.
>
Yes it is very slick. Kudos to the creator.
-sb
> -Tony