| |||||||||||||
Results of first test with 198 patches.Results of first test with 198 patches.Posted Apr 13, 2005 22:37 UTC (Wed) by mattdm (guest, #18)In reply to: Results of first test with 198 patches. by StevenCole Parent article: The guts of git
Linus seems happy with this first test. I just hope the disk usage doesn't become an issue down the road. I think "down the road" is exactly the time when we won't have to worry so much about disk usage. :)
(Log in to post comments)
Results of first test with 198 patches. Posted Apr 14, 2005 3:40 UTC (Thu) by StevenCole (guest, #3068) [Link] I think "down the road" is exactly the time when we won't have to worry so much about disk usage. :)With the continued improvement in disk storage capacity, I'm sure you're right. A related concern is network bandwidth. Not everyone has or can have a high-speed link. Here is Linus and Andrew's take on the subject:
On Tue, 12 Apr 2005, Andrew Morton wrote:
>
> Linus Torvalds (torvalds at osdl.org) wrote:
> >
> > ie we added 9MB of stuff from a set of emails that totaled a 859kB mbox.
>
> The total size of the commits list since Nov 2002 is 500MB, excluding those
> "merge" thingies.
>
> So I assume that the git tree will grow at 2GB/year.
Yes, that's within my mental envelope. I was estimating a 3-5GB git
archive for the last three years of BK work.
The good news is that the way git works, you really can put the old
history in "storage" - throw it away (and just rely on the distribution
meaning that it's _somewhere_ out there on the net) or write it on a DVD
and forgetting about it. Most people really only care about the last few
months.
Is 2GB a year a lot? I think it's peanuts, but hey, I can fill up my whole
disk with kernel trees, and I wouldn't feel it's wasted space. Others may
have slightly different priorities ("hey, I could fit 5000 songs in
there!")
Linus
Results of first test with 198 patches. Posted Apr 14, 2005 19:07 UTC (Thu) by iabervon (subscriber, #722) [Link] Hopefully, the system won't touch more history than is absolutely necessary, and it can be taught to only fetch from the home of the big disk the history it needs and doesn't have. That way, people will only download things that they actually need. Even if someone ends up with the complete history, 2GB/year is only 544 bps; so long as nobody has to wait for 5 GB to download at once, it's fine.
Results of first test with 198 patches. Posted Apr 21, 2005 15:42 UTC (Thu) by huaz (guest, #10168) [Link] I fully disagree.
It might be the right thing to do now because it's simpler to do, not because disk space is cheap. That is ALWAYS an excuse.
It's OK if git is just a linux kernel specific tool. If someone wants to make a general SCM on it, I wouldn't even want to try if I know it doesn't even support "diff".
|
|||||||||||||