3 ms·

One of the (many) major improvements of git over CVS was that CVS stored diffs., while git (not on lowest, but practicalblaxer) stores the full files. Dependin

One of the (many) major improvements of git over CVS was that CVS stored diffs., while git (not on lowest, but practicalblaxer) stores the full files. Depending on diffs made it hard to jump between versions (need to calculate the intermediate steps for any operation) while tracking full files made it possible that git could track changes even over files, thus in some cases it can even merge when code is moved between files. And for the merge: Even the "simple" merge you describe will likely lead to issues when a designer worked on improving surface to make a scene look "right" while somebody else changes the scene and the merge then goes somewhat unseen. And for that kind of stuff you don't have any unit tests as at least a safety net, as you have with code ("it compiles and tests pass - the merge didn't break anything fundamental")

gavinhoward 2y ago
About diffs, that is true, but my VCS does not use diffs. And I am aware of the combination problem, and there will be the option to lock things. But when it comes to visual things, someone does have to stare at it. If you watch https://youtube.com/watch?v=iZre2MUyvoQ https://youtube.com/watch?v=iZre2MUyvoQ , the thing you should notice is that John Lasseter is constantly checking the integration of separate parts. A director might tell a modeler and a designer to work on the same scene at the same time, as you said. In that case, I kinda expect the director to check the integration. Binary files are harder because there is no integration test, yes. But integration tests don't catch everything in code either, and people still want automatic merges.