I don't "prefer" svn (or anything else), but if you are interested in what svn does differently than git, which can suit some use cases better, here are some su

I don't "prefer" svn (or anything else), but if you are interested in what svn does differently than git, which can suit some use cases better, here are some suggestions: 1. The trivial commit graph makes some concepts easier. You know from the commit number which is more recent. There are no complex merges. 2. The above makes for useful GUIs. There are no git GUIs that a user can not aim at their own foot, and needs the real client to clean up the mess. 3. The lack of complex operations makes access control easier. You still have to manage hooks, but it's easier or at least with less unintended consequences. 4. All clones are sparse. Together with a zero copy data storage makes for some cute concepts, such as branches and tags and directories actually being the same object. Sparse clones can be very useful. 5. The system tracks file system operations, such as moves and copies. It can actually be used for things, directly and without heuristics. (This is actually the one point where I can say I prefer the svn way. Git could have done something similar without breaking the conceptual model and it would have been useful.) 6. The metadata is, or at least used to be, more developed for non-unix file systems. I'm not sure if this is still the case. 7. Storing binary data is somewhat less bad. But still bad. All that said, outside of specialized applications I'm not sure there's much reason to use svn for any new projects. And if you use it, keep in mind that git works perfectly well with svn archives. They just become a linear graph with funny commits and you can use that familiar git tools.