3 ms·
These said large code bases are usually much less of code and much more of binaries, test images or media streams, complete devtool suites, arch compilers, and
by yason 17y ago
These said large code bases are usually much less of code and much more of binaries, test images or media streams, complete devtool suites, arch compilers, and almost anything that generally would require less version control and more availability control.
In other words, stuff you would actually want to live on a network drive or some other sharing mechanism. But if it's easy enough to shove 10 gigabytes to Perforce, it will happen.
- InclinedPlane 17y agoFor some of these things, sure. But if you put your compiler tools, external binary references, etc. on some share somewhere outside of version control you will find that when you go to create a patch for some older release you are well and truly effed. Being able to sync and build with nothing but a bare OS and the relevant source is a HUGE benefit when you have to support older releases on the level that, say, Microsoft does.
- yason 17y agoIt is still the wrong solution. Disk space is cheap and what you really want is access to cumulated, unchanged old versions -- not version control: you generally don't diff or merge between compilers or test images. Instead, you can store builds of each and every gcc version you've ever used on a network disk with very little money and then properly use the version control system to have the different revisions of the source code point to the correct set of tools and resources. It's like a persistent data storage with good accessibility and no delete command. This is the only real reason why people abuse their version control system with huge binaries and it's the only reason I can think of. I shall bow to anyone who has the guts to refuse to abuse and do it properly instead.