3 ms·

I find it funny how often people look down on SVN outside of game development. It really is a great tool for that job. The trunk our of studio's SVN is hundred

• jfengel 2y ago
  What is it that SVN does particularly well here? Handle binaries?
  • gmueckl 2y ago
    Yes, SVN handles large amounts of big binary rather efficiently. It employs some binary diffing internally to keep storage usage low. The centralized model also allows optional file locking, which reduces the risk of accidental merges destroying a file. This is a major concern for files that aren't source code when no dedicated merge tool exists. Also, the centralized storage of the repo history becomes a bit of a bonus at this scale as it doesn't need to be replicated to each client, saving a little bit on disk storage and data transfers. The one unfortunate downside of SVN is the implementation of merging between branches. That relies on per-file merge histories that are partially stored in per-file properties. This is opaque, internal information, yet it is tracked the same way as file changes. This leads to situations where it's all too easy to discard some of the merge history with harmless looking operations like reverting a file between a local merge and its merge commit to get rid of an unwanted change. Once something like this happens, future merges end up doing random looking things like re-applying changes that have already been merged. This is a major part of what gives SVN its bad reputation. You really have to tread on eggshells when merging. If you can avoid the pitfalls, merging works well. But it requires rather deep knowledge of SVN and discipline.