| HN Mirror

I can't give explicit numbers, but yes I experienced some of the issues Facebook wrote about. This particular problem stems from SVN/Perforce and how they give the user the ability to only checkout part of the repo.

Setup 1 exploites this. This would be movie companies were every version of every rendering is in Perforce. On the server you have easily many times even the size of the desktop hd, and users only grab what they need/want. These companies should stick with Perforce.

Setup 2 came about from laziness. Everything was dumped into the repo with no organization. Converting it to git will require a XXXGB repo which while manageable windows can't handle well. You encounter say dozens of copies of the binary sprinkled around inside of the source directory (not even revisioned, just copied with the version included in the file name). Need a copy of every Windows NT CD's stored somewhere? Why not in the src directory!?! Once you cleanup/split this the src repo goes down to a usable size.

After the above basic cleanup (which honestly can/should have been done in svn/perforce anyway.) the src repo can still be a large size because the src isn't the src for one project, but maybe dozens or hundreds of projects that compile to one binary (or some similar setup such as lots of little binaries that are one product). It is then up to you to decide on how you want to proceed. There are a few different approaches with different pros and cons and situation specific. (And discussing them is really a full blog entry not a random hacker news comment).

I'll leave you with my law about repo size: When every developer in a company is committing to the same branch the odds that a commit will break the build increases as more developers are hired.

Edit: simplified