"SVN or Git?" usually gets answered like a tribal allegiance. It's more useful to treat it as an engineering decision: what's in the repo, who commits to it, and how big does it get? For a codebase, that points one way. For a pile of multi-gigabyte binary assets, it points another.
What Git is genuinely better at
Git is excellent, and for most software it's the obvious choice. Distributed, offline-first work; cheap branching and merging of text; an enormous ecosystem of code review, CI, and tooling built around it. If your repository is mostly source you can diff and merge line-by-line, Git is hard to beat — and nothing below is an argument against using it there.
Where Git strains on binary assets
LFS is a bolt-on, not a fix
Git's answer to large files is LFS: instead of the file, the repo stores a small pointer, and a smudge filter swaps the real content in on checkout from a separate store. It works, but it's a second system to configure, host, and keep in sync — and the large-file problem was never really Git's model to begin with.
Everyone clones everything
Git history is distributed by design, which means every clone pulls the full history of every file. For a repo full of large binaries that have been revised many times, that history is enormous, and it lands on every machine whether or not that person needs it.
No locking means clobbering
Two artists open the same .psd, both commit, and now you have a conflict that can't be merged — because binary assets can't be merged. Without a lock-before-edit workflow, the usual outcome is that somebody's work gets overwritten or painstakingly redone.
What the centralised model does instead
Subversion (and Perforce) take the opposite approach, and for assets it lines up well. Large files are first-class — commit the 2 GB asset directly, no pointers. Checkout is partial — pull just /Art and leave the rest on the server. Access is path-scoped within a single repo — no submodules to split disciplines apart. And editing is lockable — claim a binary before you work on it so nobody clobbers it.
Side by side
- Large files: Git via LFS (pointers + separate store) · SVN first-class
- Clone / checkout: Git pulls full history everywhere · SVN allows partial checkout
- Un-mergeable files: Git conflicts, no locking by default · SVN lock-before-edit
- Per-folder access: Git needs repo-splitting / submodules · SVN path-scoped in one repo
- Offline & branching of text: Git excels · SVN is centralised, weaker here
How to actually decide
Look at the repo, not the logo. If it's mostly code and your team is engineers who branch and merge all day, use Git. If it's mostly binary assets, your team is half artists and designers, and you need per-folder access and locking, the centralised model fits better — and that's the case subforge is built for.
If your repo is mostly assets, subforge fits
First-class large files, partial checkout, path-scoped access, and locking — hosted, on plain SVN. Free during beta.
Try subforge free