> Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.
Yes, and I never said you shouldn't use version control , simply that distributed version control isn't necessarily applicable (which is what the claim is).
Let's be honest, LFS is duct tape on a pig. It doesn't support SSH, for one. Mirroring a repository is mired with landmines, and probably most importantly it breaks the decentralised model of git by centralising the storage of your binary data.
> Either way, not using version control for any collaborative project is just asking for issues.
Which is not what I said, at all. The article says _distributed_ version control.
> Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.
By distributed version control you mean git here, right? The advantage of git isn't it's technical merit, or the advantages of DVCS (particularly if you're using something like LFS which turns it into a centralized VCS). The advantage of git is that it's well supported in many tools (ci, merge bits, code review, deployment, package managers). Frankly, my experience is the complexity brought on by git (which is quite a few years using it along side perforce and more recently plastic) often outweighs the benefits over something like perforce, particularly on large repos.
Yes, and I never said you shouldn't use version control , simply that distributed version control isn't necessarily applicable (which is what the claim is).
> Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/
Let's be honest, LFS is duct tape on a pig. It doesn't support SSH, for one. Mirroring a repository is mired with landmines, and probably most importantly it breaks the decentralised model of git by centralising the storage of your binary data.
> Either way, not using version control for any collaborative project is just asking for issues.
Which is not what I said, at all. The article says _distributed_ version control.
> Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.
By distributed version control you mean git here, right? The advantage of git isn't it's technical merit, or the advantages of DVCS (particularly if you're using something like LFS which turns it into a centralized VCS). The advantage of git is that it's well supported in many tools (ci, merge bits, code review, deployment, package managers). Frankly, my experience is the complexity brought on by git (which is quite a few years using it along side perforce and more recently plastic) often outweighs the benefits over something like perforce, particularly on large repos.