Now you should not put (large) binaries into a VCS. VCS is for source code, not any form of compilation output. What you store in the VCS is a script which can pull the right, uniqely defined (version, sha1, etc.) binary from some server, or a build script, which produces the binary.
Where I work, we use subversion (and I use git svn :-). We have scripts which pulls the tar.gz files for various packages in specific versions from a server, unpacks, patches and crosscompiles them to our target. The only thing we have in subversion is the scripts and the files we have changed.
For the Linux kernel we tried to have the full thing in subversion, but it took way too much for subversion, so now we only have a makefile, which clones a git repository, when the source is needed.
Posted Apr 5, 2010 3:12 UTC (Mon) by RCL (guest, #63264)
[Link]
Please understand that some software products rely on large amounts of data which is essentially a part of program and should be versioned together with source code.
It's almost like having very large firmware blobs in Linux kernels, much larger than they are currently...
See comments below where I elaborate on this interdependency between code and data in games.
Subversion considered obsolete
Posted Apr 5, 2010 14:00 UTC (Mon) by simlo (subscriber, #10866)
[Link]
It depends on wether you edit those data or not. Firmware files you don't edit. You grap a specific version, someone compiled for you, labeled and released.
On the other hand you can have data like maps and icons, which is also "source code" and belongs in the VCS if you edit them by using some program (some map editor, GIMP or whatever). But the overall system is badly designed if these files are "large". They ought to be seperated into small files, each containing seperate parts of the information and then "compiled" into larger files. This will usually make a more flexible and maintainable system (besides making life easier for the VCS). It is the same with C code: You don't make one big file but smaller ones, seperated by functionality.
Subversion considered obsolete
Posted Apr 5, 2010 3:22 UTC (Mon) by martinfick (subscriber, #4455)
[Link]
"We can do anything better than you"..."not X"..."you shouldn't do X", hmmm?
Subversion considered obsolete
Posted Apr 8, 2010 10:08 UTC (Thu) by epa (subscriber, #39769)
[Link]
It's remarkable how quickly 'my preferred tool is unable to do X' turns into the moral imperative 'you should not do X'.