3 ms·

> There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control Why do

by tomlu 12y ago

> There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control Why do you say it's bad practice? Game assets come to mind, these aren't derived artifacts and you can't build the game without them.

wtallis 12y ago
Usually, you can build the game without them, up to the final packaging stage. Almost any game that is built on an engine can have all of the asset files swapped out without having to recompile anything, and as long as the file format and structure for assets is relatively stable there doesn't have to be a tight coupling between engine versions and asset versions except when doing QA and benchmarking. This is one of the cases where git's inability to handle rewriting a public history is a pain. The art and programming departments should be able to develop along separate branches, and the programmers should be able to pull a tree from art that has everything between tags squashed (but in a reversible fashion in case there's a need to bisect something later).
- tomlu 12y ago
  There usually are dependencies between the game and its assets, but sure, these dependencies can be managed. Historically I've dealt with the problem by keeping code and assets in separate repositories (using different version control systems). While it's worthwhile to do so in order to use git for code it really is a pain.
  - colechristensen 12y ago
    Exactly my initial point. It is really worthwhile to treat code and binary data differently, and the tools don't exist to make it not-so-painful. To answer a couple of levels up, it's not bad practice because it isn't useful... there are many circumstances where having big binary blobs versioned and associated with code. It is bad practice because the tools are all written _for_ code and can get nasty when filled with binaries. So there's a problem and a solution, but nobody seems to have put together the right magic yet.

by tomlu 12y ago

wtallis 12y ago

Usually, you can build the game without them, up to the final packaging stage. Almost any game that is built on an engine can have all of the asset files swapped out without having to recompile anything, and as long as the file format and structure for assets is relatively stable there doesn't have to be a tight coupling between engine versions and asset versions except when doing QA and benchmarking. This is one of the cases where git's inability to handle rewriting a public history is a pain. The art and programming departments should be able to develop along separate branches, and the programmers should be able to pull a tree from art that has everything between tags squashed (but in a reversible fashion in case there's a need to bisect something later).

tomlu 12y ago
There usually are dependencies between the game and its assets, but sure, these dependencies can be managed. Historically I've dealt with the problem by keeping code and assets in separate repositories (using different version control systems). While it's worthwhile to do so in order to use git for code it really is a pain.
- colechristensen 12y ago
  Exactly my initial point. It is really worthwhile to treat code and binary data differently, and the tools don't exist to make it not-so-painful. To answer a couple of levels up, it's not bad practice because it isn't useful... there are many circumstances where having big binary blobs versioned and associated with code. It is bad practice because the tools are all written _for_ code and can get nasty when filled with binaries. So there's a problem and a solution, but nobody seems to have put together the right magic yet.