Hacker News Reader

Partitioning is the answer. In a repo that size 99% of the history is useless to anyone. You wouldnt manage a database like this so why force SCM down this path?

If they used git with say only the last year of history in it they would be having zero issues.

View on HN

Partitioning may be the answer but this is a huge problem for corporations like Facebook (and the one I am working for). If things have been done with one giant repo from day one, splitting it is going to be a major engineering/political/social problem when there's thousands of engineers working on the code base and you can't just shut down business for the duration of the migration.

While true, you only need 1% of the history, the problem is WHICH 1% and when?

Tracking down bugs in the history is a huge deal, and its often absolutely critical. And yes, regressions go past 1 year.

Reply on news.ycombinator.com