3 ms·
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 pa
by greatsuccess 13y ago
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.
- ryanobjc 13y agoWhile 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.
- exDM69 13y agoPartitioning 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.